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

From: Francesca Palombini <[email-masked]>
Date: Mon, 3 May 2021 10:39:28 +0000

Hi all,

Murray and I are still looking for guidance from the community on how to process the Haptics proposal discussed in Dispatch at IETF109:

https://datatracker.ietf.org/doc/html/draft-muthusamy-dispatch-haptics-01 

During the IETF109 meeting (minutes: https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous mailing list discussion [1], there was general support on progressing this work. Murray has previously asked the mailing list if the community thinks this is better done as either a short-lived working group or as AD sponsored [2], but got no answer. This is concerning for us, as if there is no energy to work on this proposal, spinning a wg out of it with enough active participants or even getting enough reviews to ensure IETF consensus might not be doable. So this is us reaching out one more time to hear if there is interested people who would be willing to get involved, and if so hearing your opinion if you think this should go through as AD sponsored or will need its own wg (my preference).

Francesca

[1] https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-DrgOR5I0oSDcQ/ 
[2] https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHlF3FHjT8Tmi3k/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 May 2021 12:17:55 +0100

Hi Francesca,

I think this would be fine as AD-sponsored with discussion on the
[email-masked] list.  I am willing to review the document when last-called.

regards,

Ted Hardie

On Mon, May 3, 2021 at 11:40 AM Francesca Palombini <francesca.palombini=
[email-masked]> wrote:

> Hi all,
>
> Murray and I are still looking for guidance from the community on how to
> process the Haptics proposal discussed in Dispatch at IETF109:
>
> During the IETF109 meeting (minutes:
> https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous
> mailing list discussion [1], there was general support on progressing this
> work. Murray has previously asked the mailing list if the community thinks
> this is better done as either a short-lived working group or as AD
> sponsored [2], but got no answer. This is concerning for us, as if there is
> no energy to work on this proposal, spinning a wg out of it with enough
> active participants or even getting enough reviews to ensure IETF consensus
> might not be doable. So this is us reaching out one more time to hear if
> there is interested people who would be willing to get involved, and if so
> hearing your opinion if you think this should go through as AD sponsored or
> will need its own wg (my preference).
>
> Francesca
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-DrgOR5I0oSDcQ/
> [2]
> https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHlF3FHjT8Tmi3k/
>
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 May 2021 06:09:59 -0700 (PDT)

> https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and previous mailing
> list discussion [1], there was general support on progressing this work. Murray
> has previously asked the mailing list if the community thinks this is better
> done as either a short-lived working group or as AD sponsored [2], but got no
> answer. 

We need a media types working group, because there are several media type
related matters that warrant attention. The ones I know about are:

(0) This haptics top-level type.

(1) The proposal to allow multiple media type suffixes.

(2) Media types for programming languages

(3) Improved guidelines for constructing media type security considerations.

This is not intended to be a comprehensive list: There may be other
things that I have forgotten or don't know about.

Also note that my listing these things does not mean I think the work is a great
idea - I'm fairly skeptical of the multiple suffix idea. The only one where I
have real skin in the game is (3), and I'm working on an I-D for it. I'm also
willing to act as an editor for the programming language document, and review
the other work.

> This is concerning for us, as if there is no energy to work on this
> proposal, spinning a wg out of it with enough active participants or even
> getting enough reviews to ensure IETF consensus might not be doable. So this is
> us reaching out one more time to hear if there is interested people who would be
> willing to get involved, and if so hearing your opinion if you think this should
> go through as AD sponsored or will need its own wg (my preference).

I can't speak to the energy level of others, but I would suggest asking about
it on the media types list. My guess is a significant number of people involved
in media types don't subscribe to this list.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 May 2021 09:59:53 -0400

Francesca,

Like others, I think this work is worth progressing.  However,
precisely because of that, and because new top-level media types
are a big deal with a potential interoperability mess if we get
them wrong, I'm a little nervous about pushing a specification
written by two people from the same company through on AD
sponsorship.  I think what we know from patterns of Last Calls
in the last few years is that, for a topic on which most IETF
participants have little in-depth knowledge and/or interest, the
Last Call will either produce silence or comments similar to
those during the DISPATCH meeting: "seems like a good idea but I
can't evaluate the technical details.

So I'd like to see a WG.  And, if the WG cannot get interest and
energy from a significant number of people from multiple
organizations, then there is an issue we should not overlook or
accidentally suppress: silence,whether on a Last Call or
otherwise, from everyone but a document's authors/proponents
does not IETF consensus make.

I just noticed Ned's note and agree with everything he says.
The comments above get to the same conclusion he reaches
although from a different direction.  And I favor a media types
WG over one specifically for the Haptics proposal alone for the
reasons he gives and one he implies: it would be significantly
more likely to draw significant participation.

best,
    john

--On Monday, 03 May, 2021 10:39 +0000 Francesca Palombini
<francesca.palombini=[email-masked]> wrote:

> Hi all,
> 
> Murray and I are still looking for guidance from the community
> on how to process the Haptics proposal discussed in Dispatch
> at IETF109:
> 
> https://datatracker.ietf.org/doc/minutes-109-dispatch/ ) and
> previous mailing list discussion [1], there was general
> support on progressing this work. Murray has previously asked
> the mailing list if the community thinks this is better done
> as either a short-lived working group or as AD sponsored [2],
> but got no answer. This is concerning for us, as if there is
> no energy to work on this proposal, spinning a wg out of it
> with enough active participants or even getting enough reviews
> to ensure IETF consensus might not be doable. So this is us
> reaching out one more time to hear if there is interested
> people who would be willing to get involved, and if so hearing
> your opinion if you think this should go through as AD
> sponsored or will need its own wg (my preference).
> 
> Francesca
> 
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/dispatch/Tv-4_ZUwASBjs-D
> rgOR5I0oSDcQ/  [2]

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 May 2021 07:27:52 -0700 (PDT)

+1 to everything John said here. There are a number of restrictions on different
top-level types in some protocols, and we need unusually broad participation to
get at all of them.

				Ned

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 3 May 2021 16:49:38 +0200 (CEST)

yes John and Ned, it IS a good idea to have sug a registry, otherwise, as 
the I-D itselfs point out, we will end in complete divergent proprietary 
implementations. But to ensure the solution, although simple and in line 
with other registries, needs to be agreed at least by people who are 
working implemnting these solutions... so John's objection "two aut=rhots 
from the same company" worries me a bit. I'd like to have a revision (or 
even co-authoring) at leaset from Apple, Google and others.

Just to be sure we creare a usable specification, no other reason... but 
it's important to check we agree and there is consensus.

A "convened" short life WG ?

just my 2 cents.

all the best
Claudio

>> https://mailarchive.ietf.org/arch/msg/dispatch/GIYE2v8UkxkBVHl

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 May 2021 08:15:22 -0700 (PDT)

Accidently omitted one item from the list that I *did* know about:

(4) Review the format of the media type registry. One suggestion, which
    I think came from John Klensin, was that given media type names can be
    grandfathered, the name itself isn't a reliable indicator of the
    of the tree, so a column listing the tree the type is in would be
    helpful.

				Ned

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 3 May 2021 16:13:14 +0000

Hi all,

>         of the tree, so a column listing the tree the type is in would be

Ned also suggested to get input from the media-type mailing list, which is a very good idea, hence this email.

I am interested to hear your opinion, if you think creating such a wg would be a good idea and you'd participate in it, if you have proposals that would fit in such a wg, and especially if you'd be willing to actively help the wg creation (help out with chartering, chairing etc). On my side, and speaking only for myself, I have been warned of long running working groups, but I am not against it if there is enough interest and people are willing to put in the time and effort to make this work.

Francesca

[1] thread starting here https://mailarchive.ietf.org/arch/msg/dispatch/tWCxfDGYCoTcXld1anEGewYI05c/ for context

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 May 2021 17:29:33 +0100

I think the set of work items Ned lays out might well be the basis for a
working group.  I have concerns, however, with including the registration
for a haptics top-level type in that work.

As the draft points out, there is a good bit of active work going on
related to haptics in other forums (e.g. the MPEG Systems File Format
sub-group).  If the work on registering a top-level haptics type is
interspersed with work on multiple media type suffixes and media types for
programming languages, I have concerns about the speed with which it can
complete.  If we want to see haptic signals be treated appropriately as a
media type, I suspect the time we have to do it is not unbounded.  My
personal advice is thus to progress the haptics work separately.  If that
means as an ad-sponsored draft, I'm personally okay with that, but I think
the best other option is to do it as its own short-lived group.  The other
work (and the relevant expertise) is pretty distinct.

Just my personal opinion,

Ted

---

From: Yeshwant Muthusamy <[email-masked]>
Date: Mon, 3 May 2021 17:27:08 +0000

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. 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.

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://www.iso.org/standard/81604.html

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://www.mpegstandards.org/standards/Explorations/40/.

I present the above information not as conclusive evidence, but as valid data points to be considered in our discussions on this I-D.

I look forward to the next steps and to answering any questions on the content of the I-D itself.

Thanks,
Yeshwant

Yeshwant Muthusamy, Ph.D. | Senior Director, Standards
[email-masked]<mailto:[email-masked]> | +1 469-583-2171

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

I think the set of work items Ned lays out might well be the basis for a working group.  I have concerns, however, with including the registration for a haptics top-level type in that work.

As the draft points out, there is a good bit of active work going on related to haptics in other forums (e.g. the MPEG Systems File Format sub-group).  If the work on registering a top-level haptics type is interspersed with work on multiple media type suffixes and media types for programming languages, I have concerns about the speed with which it can complete.  If we want to see haptic signals be treated appropriately as a media type, I suspect the time we have to do it is not unbounded.  My personal advice is thus to progress the haptics work separately.  If that means as an ad-sponsored draft, I'm personally okay with that, but I think the best other option is to do it as its own short-lived group.  The other work (and the relevant expertise) is pretty distinct.

Ted

On Mon, May 3, 2021 at 4:24 PM Ned Freed <[email-masked]<mailto:[email-masked]>> wrote:
Accidently omitted one item from the list that I *did* know about:

                                Ned

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.ietf.org%252fmailman%252flistinfo%252fdispatch%26c%3DE%2C1%2CVi9k7g1GlUgTKBv27ALBsxuQOA-rlwSwQRsdeZ3gTv6YpnkKNh73VKDNYYkFuAGYy9Cyv0WYnXhq4imxM7WvvKE8LL9JkfTEvoVXieOYXeSj%26typo%3D1&data=04%7C01%7C%7C73e586cd1d774d9b2f1908d90e50b9de%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C637556562154088590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FVAduOChguL3ekxG%2B4nW3yYQqzwycZkILVS4rIYwKaI%3D&reserved=0>

---

From: Yeshwant Muthusamy <[email-masked]>
Date: Tue, 4 May 2021 00:12:41 +0000

Ned,

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

Regards,

Yeshwant

[email-masked] | +1 469-583-2171

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

> 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

---

From: Yeshwant Muthusamy <[email-masked]>
Date: Tue, 4 May 2021 00:18:28 +0000

Claudio,

I was reacting specifically to the following line in your original email (the underlining of the word 'co-authoring' is mine):

>>I'd like to have a revision (or even co-authoring) at leaset from Apple, Google and others.

I will leave it at that.

Regards,

Yeshwant

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

>> 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),

you totally misread what I stated, sorry. I said that at least those companies who are implementing the "new stuff" should be involved into the discussion of the specificaions, oitherwise the specification will be just ignored or result inaccurate compared to reality. And Apple and Google are just 2 examples. The way you read my sentence it totaly against what IETF is how it works etc. When I (and Ned and John, and many of the people who made suggestions in tis thread) started in the IETF, Apple, Google, and 80% of current companies weer "just not yet stablished", so please do not misread examples. :-) Specifications are done and are successful when all people who need them work to write them, and when people who will implement them work on them, too.

apart frm this, +1 to Ned's last email.

> 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.

yes!

Claudio Allocchio             G   A   R   R          [email-masked]<mailto:[email-masked]>

                         Senior Technical Officer

      PGP Key: https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.cert.garr.it%252fservizi%252finformazioni-su-pgp-keys%26c%3DE%2C1%2C-GTUZFGQdXv1p694QMmj1sboEwalq1CLyrRlB-PM9e7iQ5szrRm6OpyckAhxnSk2d8ObumtibdgcLcJfnSN_TW--yHCwqIEObJRv3_zTuuOk%26typo%3D1&amp;data=04%7C01%7C%7C6115199e24f6457dcad108d90e6a4141%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C637556671794269703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=OkQt7jhvQQ4g8gjGnRXiz0Px0Idrtj1hZuQsQOxtcAU%3D&amp;reserved=0

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 May 2021 22:09:22 -0400

--On Monday, May 3, 2021 16:13 +0000 Francesca Palombini
<francesca.palombini=[email-masked]> wrote:

>...

>> (4) Review the format of the media type registry. One
>> suggestion, which I think came from John Klensin, was that
>>         given media type names can be grandfathered, the name
>>         itself isn't a reliable indicator of the of the tree,
>>         so a column listing the tree the type is in would be
>>         helpful.

>...
> I am interested to hear your opinion, if you think creating
> such a wg would be a good idea and you'd participate in it, if
> you have proposals that would fit in such a wg, and especially
> if you'd be willing to actively help the wg creation (help out
> with chartering, chairing etc). On my side, and speaking only
> for myself, I have been warned of long running working groups,
> but I am not against it if there is enough interest and people
> are willing to put in the time and effort to make this work.

Francesca,

I don't know what Ned had in mind but, to me, the list above is
not open-ended and the sort of thing that would require a WG
with an open-ended charter and schedule.  Each of the issues Ned
raised is a (more or less) new strategic question [1] and they
are probably best thought of that way rather than as individual
open-ended tasks.

Taking the Haptics proposal as an example, Ned should check and
confirm this but my recollection from when what is now the media
type model was first designed was that we expected very few new
top-level types and wanted it to be hard, probably even at the
"only if there is no possible other choice" level.   Based on
reading the draft and the discussion during the DISPATCH
meeting, I suspect haptics might qualify.  But a WG discussion,
both of that proposal and about what light it sheds on the
situation and what we have learned in 30 years about what the
criteria for top-level types should be.   Can we design criteria
good enough that expert review is appropriate?  Should we
convene a WG for each proposed top-level type and, if so, where
will the energy come from?  Are there better models.  For
example for this particular proposal, if the real expertise and
interest is in an MPEG group [2], would it be sensible to define
criteria for top level types so that some sort of "specification
from recognized standards body" model would work, perhaps with
the IETF setting up an advisory team (the media-types mailing
list might or might not be appropriate).  I don't have answers,
but these are the types of questions a WG ought to be able to
address and answer within some plausible time.

Media type suffixes are another example.   What is needed is an
effort to think through the example proposals we have seen and
others people might come up with and either decide they are a
bad idea or establish evaluation criteria.  I hope we would not
need a WG for each possible suffix, but we almost certainly need
one to establish and reach consensus on some principles.

And so on for the rest of the list.  Won't be easy, but I don't
think it is open-ended.

best,
   john

[1] "More or less" because a few have been around, not dealt
with, for a while so the "new" part is deciding to deal with
them.

[2] I'm going to try to write a response to Ted's comments about
the need to do something soon, but will keep it separate from
this note.

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 May 2021 23:47:46 -0400

(adding the media-types list and doing a bit of trimming)

--On Monday, May 3, 2021 17:29 +0100 Ted Hardie
<[email-masked]> wrote:

> I think the set of work items Ned lays out might well be the
> basis for a working group.  I have concerns, however, with
> including the registration for a haptics top-level type in
> that work.
> 
> As the draft points out, there is a good bit of active work
> going on related to haptics in other forums (e.g. the MPEG
> Systems File Format sub-group).  If the work on registering a
> top-level haptics type is interspersed with work on multiple
> media type suffixes and media types for programming languages,
> I have concerns about the speed with which it can complete.
> If we want to see haptic signals be treated appropriately as a
> media type, I suspect the time we have to do it is not
> unbounded.  My personal advice is thus to progress the haptics
> work separately.  If that means as an ad-sponsored draft, I'm
> personally okay with that, but I think the best other option
> is to do it as its own short-lived group.  The other work (and
> the relevant expertise) is pretty distinct.

Ted,

As you have probably figured out from my recent notes responding
to Francesca and Claudio, I have a slightly different take on
this, again somewhat different than Ned's comments.  One reason
is that I think it would be really unfortunate to establish a
precedent that the way to get a top-level media type is to
invoke work going on at what I understand to be essentially the
WG level in another SDO and then plead urgency.  I would feel
somewhat differently about an established, recognized, deployed
international standard, but, as I understand "active work in ...
MPEG Systems File Format sub-group", this is fairly far from
that.

Analogies to other bodies treating I-Ds as if they are finished,
consensus, IETF work product are probably useful here.

So, in the hope that the IETF is still an organization in which
we can figure out what the right thing is to do and then make
the procedures work with it, let me suggest something which may
be a bit of a strawman:

(1) We get the WG that Ned proposed going, with adjustments as
suggested.  Getting it going should not take long, e.g., no one
as proposed a BOF or two as prerequisites.   The first charge
for that WG should be to review prior work discuss criteria for
new top-level media types.  I would hope that can be done fairly
quickly.  If we cannot reach at least sufficient agreement to
conclude that a Haptics top level type would be reasonable
(independent of the details of how it is defined and who is
defining it, much less candidate subtypes) then I suggest the
proposal is dead in the water independent of what other bodies
are or are not doing.

(2) Probably in parallel with the above, Francesca (or Murray)
do a call for volunteers who are familiar with and involved in
work on Haptics, in the MPEG group, in their "day job" settings,
or elsewhere.  Where they are tapped as participants in a
short-lived WG or as reviewers of a potential AD-sponsored
document is probably unimportant, as long as they represent
diverse perspectives.  The numbers, expertise, and industry
coverage are important.  Based on the outcome of that poll, they
reach a conclusion as to whether meaningful, informed, IETF
consensus on the details of the proposal (presumably a revised
I-D) is plausible.

(3) If the outcome of (2) is that we have a sufficient number of
such people, I don't have a strong preference between
AD-sponsored and a short-lived WG.  However, the less clear the
criteria are that emerge from (1) --or if the early result of
that effort is general principles but not anything we would
consider criteria-- the more I think a WG is needed.

(4) If the outcome of (1) is that a Haptics top-level type is
plausible but that of (2) is that we don't have, in the judgment
of the ADs,  the right combination of expertise, interest, and
energy, then I suggest we cut a deal with the MPEG effort (close
to one end of the pipeline) and/or the relevant ISO TC (the
other end) in which we promise them that we will allocate the
top-level media type and delegate responsibility for defining
subtypes to them as soon as they tell us that a standard that
described the properties and use of that type is finished (not
being worked on, but finished).  Note that punts the question of
how subtypes are evaluated and decided upon to another body.
Otherwise, that question is one of the harder issues facing the
question of criteria for a new top-level type (and a subject on
which I, personally, think the current I-D is fairly weak).

I don't know if it would be possible to complete the above
before IETF 111, but, if not, we ought to be able to come fairly
close.  And it is _really_ pragmatic.

  best,
   john

[1[
https://mailarchive.ietf.org/arch/msg/dispatch/RRIs5MxWbQuF9kJJclJ-KsFQNIg

[2]
https://mailarchive.ietf.org/arch/msg/dispatch/zE9eMvNXpCXF1LWAMt3y-_2GjJ0

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 May 2021 10:06:18 +0100

Hi John,

Response in-line.

> consensus, IETF work product are probably useful here.
I believe the issue here isn't the state of the standards-making in another
body but the core proposition of the effort:  haptic signals are media.
There are a lot of consequences of that core proposition, the most
important of which for me are that these signals can be bound with other
media into coherent multimedia resources and that we can build
interoperable standards that allow both haptic media and these multimedia
resources to be handled by any compliant systems that follow that
standard.  (The other obvious way to model them, as application
instructions, leaves us in a very different place).

If we agree with that core proposition, than incorporating haptic signals
into the media types and other aspects of media processing that are under
the aegis of the IETF is the right thing to do, and the time to start that
work is now, when it is still possible to have the aspects of the system
handled elsewhere adjusted more readily.  Waiting until that work is
completed strikes me as what I grew up hearing called "the wrong mistake".

We could also, of course, ignore the work and that proposition.  The likely
outcomes of that, in my hazy crystal ball, is either that the relevant work
will create a MIME-like system that looks like but isn't quite actually
MIME (which means that all of the other media types which are consumed by
that system will have to deal with being part of two subtly different
systems) or that deployed systems will squat on a string in a way that
simply routes around our registry and rules.  I am sure you can supply the
examples which lead me to that conclusion pretty readily.

I have not replied to your proposal below to cede the territory to another
body, simply because I think a major point of any effort in this space is
how multimedia works rather than how single-medium signals are consumed.
That being the case, I don't think we can cede without ceding much more of
the multimedia landscape than I think you intended.

Just my opinion, of course.

regards,

Ted Hardie

---

From: Yeshwant Muthusamy <[email-masked]>
Date: Tue, 4 May 2021 17:37:11 +0000

John,

Regarding your comment:

>> One reason is that I think it would be really unfortunate to establish a precedent that the way to get a top-level media type is to invoke work going on at

>>what I understand to be essentially the WG level in another SDO and then plead urgency.

>>I would feel somewhat differently about an established, recognized, deployed international standard, but, as I understand "active work in ..

>>MPEG Systems File Format sub-group", this is fairly far from that.

I would just reiterate/summarize what I wrote in my response to Ned's comment that you might have missed: the haptics proposal in MPEG is no longer at the "WG level" in the MPEG Systems File Format sub-group. It just progressed to FDIS ballot at MPEG134, which should complete by July 2021, at which point progression to IS (International Standard) is just a matter of procedure. More to the point, it has passed two rounds (CDAM and DAMD) of international balloting, with over 20 ISO National Bodies casting their ballots in each round. No objections to the haptics proposal were received in either round.  The proposal left the "WG level" after MPEG131 in July 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot after MPEG132 in October 2020 - a fact that was indeed mentioned in v01 of the I-D.

The ISO link to the DAMD is here: https://www.iso.org/standard/81604.html<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstandard%2F81604.html&data=04%7C01%7C%7Cb9be185f21b44df1b2f708d90e58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C637556596669589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qwZKX%2B26UWRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=0>.

To be clear, I have no issues with the other points you raise. Just want to make sure that the discussion is based on current reality.

Thanks,

Yeshwant

-----Original Message-----
From: John C Klensin <[email-masked]>
Sent: Monday, May 3, 2021 10:48 PM
To: Ted Hardie <[email-masked]>
Cc: Dispatch WG <[email-masked]>; [email-masked]; Applications and Real-Time Area Discussion <[email-masked]>; ART ADs <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH?

--On Monday, May 3, 2021 17:29 +0100 Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

> I think the set of work items Ned lays out might well be the basis for

> a working group.  I have concerns, however, with including the

> registration for a haptics top-level type in that work.

> interspersed with work on multiple media type suffixes and media types

> for programming languages, I have concerns about the speed with which

> it can complete.

> If we want to see haptic signals be treated appropriately as a media

> type, I suspect the time we have to do it is not unbounded.  My

> personal advice is thus to progress the haptics work separately.  If

> that means as an ad-sponsored draft, I'm personally okay with that,

> but I think the best other option is to do it as its own short-lived

> group.  The other work (and the relevant expertise) is pretty

> distinct.

Ted,

As you have probably figured out from my recent notes responding to Francesca and Claudio, I have a slightly different take on this, again somewhat different than Ned's comments.  One reason is that I think it would be really unfortunate to establish a precedent that the way to get a top-level media type is to invoke work going on at what I understand to be essentially the WG level in another SDO and then plead urgency.  I would feel somewhat differently about an established, recognized, deployed international standard, but, as I understand "active work in ...

MPEG Systems File Format sub-group", this is fairly far from that.

Analogies to other bodies treating I-Ds as if they are finished, consensus, IETF work product are probably useful here.

So, in the hope that the IETF is still an organization in which we can figure out what the right thing is to do and then make the procedures work with it, let me suggest something which may be a bit of a strawman:

(1) We get the WG that Ned proposed going, with adjustments as suggested.  Getting it going should not take long, e.g., no one

for that WG should be to review prior work discuss criteria for new top-level media types.  I would hope that can be done fairly quickly.  If we cannot reach at least sufficient agreement to conclude that a Haptics top level type would be reasonable (independent of the details of how it is defined and who is defining it, much less candidate subtypes) then I suggest the proposal is dead in the water independent of what other bodies are or are not doing.

(2) Probably in parallel with the above, Francesca (or Murray) do a call for volunteers who are familiar with and involved in work on Haptics, in the MPEG group, in their "day job" settings, or elsewhere.  Where they are tapped as participants in a short-lived WG or as reviewers of a potential AD-sponsored document is probably unimportant, as long as they represent diverse perspectives.  The numbers, expertise, and industry coverage are important.  Based on the outcome of that poll, they reach a conclusion as to whether meaningful, informed, IETF consensus on the details of the proposal (presumably a revised

I-D) is plausible.

(3) If the outcome of (2) is that we have a sufficient number of such people, I don't have a strong preference between AD-sponsored and a short-lived WG.  However, the less clear the criteria are that emerge from (1) --or if the early result of that effort is general principles but not anything we would consider criteria-- the more I think a WG is needed.

(4) If the outcome of (1) is that a Haptics top-level type is plausible but that of (2) is that we don't have, in the judgment of the ADs,  the right combination of expertise, interest, and energy, then I suggest we cut a deal with the MPEG effort (close to one end of the pipeline) and/or the relevant ISO TC (the other end) in which we promise them that we will allocate the top-level media type and delegate responsibility for defining subtypes to them as soon as they tell us that a standard that described the properties and use of that type is finished (not being worked on, but finished).  Note that punts the question of how subtypes are evaluated and decided upon to another body.

Otherwise, that question is one of the harder issues facing the question of criteria for a new top-level type (and a subject on which I, personally, think the current I-D is fairly weak).

I don't know if it would be possible to complete the above before IETF 111, but, if not, we ought to be able to come fairly close.  And it is _really_ pragmatic.

  best,

   john

[1[

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org%252farch%252fmsg%252fdispatch%252fRRIs5MxWbQuF9kJJclJ-KsFQNIg%26c%3DE%2C1%2C6G6eDTk9mcWs8uM122hKaDB0VrG8GnkKRboPw6fB2_Uk0RCPxB0I4AJmz_kiaV6x6hH9YVFkCIjyUrDrCvar10bLNPZHxnhFl2vdY6YRZpbwR-x73Q%2C%2C%26typo%3D1&amp;data=04%7C01%7C%7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2woxbmYzryVC8LwiaH3%2FQqX3MpKmy6swcrYTRJABu0A%3D&amp;reserved=0

[2]

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fmailarchive.ietf.org%252farch%252fmsg%252fdispatch%252fzE9eMvNXpCXF1LWAMt3y-_2GjJ0%26c%3DE%2C1%2ChatQi5r0UG0Mih2C0qTKWqSwanmSjZB1qP6OUtqmoEv54rvdqzNMzyWS0pGKI22pTuojS3pMRy-JXiQ9VV5jflqvNUmH3UZysPJ6zpaBLbNBf3Z8L6oychaJolb2%26typo%3D1&amp;data=04%7C01%7C%7C0c8685de1863484c353008d90eaf6c6a%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C637556968891437551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=RdVZ172jKG0Z31HPBVVeuZgZ916IbaB36dFom6A9rXA%3D&amp;reserved=0

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 May 2021 13:56:50 -0400

Hi, Ted,

Also inline, with much trimmed.  As a preview, I can, and
largely do, agree with your "core proposition".  I just question
whether this draft represents the level of maturity appropriate
for AD sponsorship [0], whether the IETF is ready and has the
energy and competence to do the work, and whether a top-level
media type is appropriate and/or under what conditions.   Based
on what I have seen so far, I think the answer to all three
questions is "no".  The answer to the first and third is
normally "WG".  And the answer to the second is "try to figure
out a different way to get the work done".   Details below.

 
> I believe the issue here isn't the state of the
> standards-making in another body but the core proposition of
> the effort:  haptic signals are media. There are a lot of
> consequences of that core proposition, the most important of
> which for me are that these signals can be bound with other
> interoperable standards that allow both haptic media and these
> multimedia resources to be handled by any compliant systems
> that follow that standard.  (The other obvious way to model
> them, as application instructions, leaves us in a very
> different place).
> 
> If we agree with that core proposition, than incorporating
> haptic signals into the media types and other aspects of media
> processing that are under the aegis of the IETF is the right
> thing to do, and the time to start that work is now, when it
> is still possible to have the aspects of the system handled
> elsewhere adjusted more readily.  Waiting until that work is

>From a very high-level view, I agree with the above.  However,
it does not follow from "incorporating haptic... into the media
types" that a top-level type is needed, nor that this I-D is a
necessary and sufficient proposal to do that.  As a specific
example, MPEG was incorporated as a subtype under "video" from
the very beginning of MIME multimedia work despite normally
including audio elements.  Its subsequent variants and offspring
have been allocated there too.  I observe that the work in other
SDOs seems to be done in MPEG-related groups: that does not mean
"haptics" should not be a top-level type, but it does not
strengthen the case.  Could this be done as an "application"
subtype with appropriate parameters?  Perhaps.  And that would
certainly be the default for haptics as soon as someone pointed
out that no video was needed.  

Keep in mind that the naming part of the media type registration
model is ultimately about the names by which things are called
within a set of protocols, rather than the things themselves, or
even about what people call them. If the proposal were, e.g., to
allocate application/haptics (or even video/haptics), I assume
the discussion would be mostly with Ned (and potentially Murray
and Alexey) as type reviewers and not on the ART or DISPATCH
lists.  It would be mostly about whether the definition in the
document (including whatever stable or unstable references it
pointed to) was adequate and not about a fundamental principle
about how media type names and registrations are organized.

I think that, in the long term, the IETF lives or dies based of
the quality of its work.  Getting into so much of a hurry about
this that we ignore fundamental considerations would be, IMO, a
different "wrong mistake".

Perhaps equally important to my reaction to your core principle,
I don't see anything in either the I-D or the discussion that
follows that asks or expects the IETF to get involved in the
actual definitions or protocols associated with haptics.  What I
get from the draft is that there is a new media thing here and
that the IETF is being asked at assign a label -- a media type,
but remembering that RFCs 2046 and 4289 define that as a
type/subtype combination [1], not necessary a top-level one
although that is what the I-D proposes.   If someone came to us
and said "we'd like the IETF to be involved in designing how
haptics work, how the data structure for transmitting haptic
information is to be defined and organized, and/or how new
protocols for transmitting and presenting haptic information (or
delivering vibrations to your fingers or seat) are defined, than
we would be having a different conversation (from my point of
view, even more about expertise in the IETF).  But, as far as I
can tell, we have not been offered that opportunity and neither
MIME, nor the web, nor any other application that uses media
types care very much (except for defaults with some known types
and unknown subtypes used with them) what things are called,
only how the data are organized and whether that organization is
well-defined and implemented.   If you, or someone else, want to
make a proposal that we be involved that way, possibly in
competition with other groups, by all means write it.

But, as I stands, I see only a request for a name and so I would
suggest that the authors (and the IETF might reasonably choose
among the following:

(1) Go with application/haptics (or video/haptics but I'm
personally convinced by the authors' argument about that)  and
define it now, in a way that is satisfactory to the media-types
list and the reviewers.

(2) Make a deal with the reviewers that the subtype should be
registered new with an informal and incomplete definition but
that a more complete definition will come along when the work in
MPEG and ISO get further along.  The current rules don't
encourage that (for good reason) but don't explicitly prohibit
it either... and it might be The Right Thing to do for the
reasons you indicate.

(3) Insist that a top-level type is needed, but accept the fact
that such requests are, and should be, subject to very careful
scrutiny, scrutiny that necessarily include a review of what we
consider appropriate for a top-level type for which there is not
already significant experience and very stable specs (it is not,
e.g., a situation akin to the request for "font/").

The first should be relatively quick and focus on adequacy of
definition rather than question of whether haptic or
haptic-related data are appropriate for some sort of media type
registration (which, IMO, has never been in doubt-- again
agreeing with your core proposition).  The second, even quicker,
especially if it comes via a formal request from another
recognized standards organization (then the ADs would not even
need to be involved except maybe for another round on
"recognized").  If the third is really the preference, then a WG
to examine the issues, the criteria, and probably even the
merits of this proposal is the price one pays.  To which the
request remains one of a new top-level type, the time that might
take and the tradeoffs involved are really the authors' issue
and problem, not the IETF's.

> We could also, of course, ignore the work and that
> proposition.  The likely outcomes of that, in my hazy crystal
> ball, is either that the relevant work will create a MIME-like
> system that looks like but isn't quite actually MIME (which
> means that all of the other media types which are consumed by
> that system will have to deal with being part of two subtly
> different systems) or that deployed systems will squat on a
> string in a way that simply routes around our registry and
> rules.  I am sure you can supply the examples which lead me to
> that conclusion pretty readily.

I can indeed, but I think you are presuming more involvement by
the IETF in the definition of data structures and protocols than
I think has been asked for or offered (again as a handy example,
note that the IETF had zero involvement in defining MPEG itself
-- we just assigned a label to an existing spec -- and there is
no evidence that either MIME or the Internet have been worse for
the experience).  Now, if there were something in this proposal
(or some proposal that would likely emerge without IETF
involvement) that required a different type naming structure or
syntax or that created a subtype of, say, "text/", that would be
a problem, not just for MIME but for everything that now depends
on MIME structures that someone might want to adapt in the
future for haptics.  So, yes, we should facilitate their getting
a name and should, if asked, advise against stupidity.  But,
beyond that, the only thing MIME --as a set of structures and
principles-- cares about is that a stream of bits are
transmitted in some contained way.   I suppose that, if the data
to be transmitted came in Qbits, Frozzles, or some sort of three
or four dimensional data arrangement that could not be reified
into a stream, there would be a problem in which it would be
very important for the IETF to be involved.   But not only is
that not being proposed by this I-D but it is certainly nothing
we'd want to hurry through.
 
> I have not replied to your proposal below to cede the
> territory to another body, simply because I think a major
> point of any effort in this space is how multimedia works
> rather than how single-medium signals are consumed. That being
> the case, I don't think we can cede without ceding much more of

I agree with that as a principle, but I don't see a proposal yet
-- from you, the authors (in the I-D or otherwise), or anyone
else, to get the IETF involved in the relevant protocol
definitions or the haptics part of "how multimedia works".  From
that point of view, the issue is not ceding the territory to
others but having it brought to us, pre-ceded, with what it
really just a request for a name (again, not that much different
from, e.g., what became video/H263-2000 or video/mp4).  I can
see a very strong case for the IETF being more actively involved
in how multimedia works, or possibly in producing a document
like RFC 6416 (which defined MP4V-ES), but the current I-D-
isn't any of those things and, AFAICT, we have no proposal, or
even the beginning of a proposal, in front of us for that sort
of work. 

> Just my opinion, of course.

And mine.

best,
   john

[0] I don't know that it has ever been formalized and don't know
that trying to do so would be a good idea, but one working
definition of "appropriate for AD sponsorship" includes at least
one of two elements.  One is that it is important to be
published in the IETF Stream, but no one other than the authors
really care or it is presented as their opinion and the impact
on the rest of the Internet is likely to be minimal.  The other
is that there are no controversial issues, especially those of
the variety that sorting out during IETF Last Call does not work
well or provide confidence about informed IETF consensus.  The
authors' arguments in the draft and yours about impact on MIEM
argue against the first case.   I think the question of whether
this, as defined in the I-D should be a top-level type is
clearly controversial even if the question of whether some name
should be assigned is not. 

[1] That terminology may have been a mistake and/or
confusion-prone, but sorting it out is just another argument for
the WG Ned suggested.

---

From: Ned Freed <[email-masked]>
Date: Tue, 04 May 2021 11:10:01 -0700 (PDT)

> instructions, leaves us in a very different place).

This statement appears to be based on a misunderstanding of the semantics of the
"application" top level media type. 

The use of the application top-level type in not limited to content consisting
of, or which is modeled as, "application instructions".  

This is clearly stated in RFC 6838 section 4.2.5:

   The "application" top-level type is to be used for discrete data that
   do not fit under any of the other type names, and particularly for
   data to be processed by some type of application program.  

Applications process media streams all the time, so even the second part of this
in no way prohibits the use of application for media that doesn't fit under
"audio" or "video" - as haptics clearly does not - and which is modeled
as a media stream.

Now, you may not like the fact that "application" was chosen to be the name for
the catch-all top-level type. Truth be told, I don't much care for it either.
But at the time this stuff was decided, this was the best we could come up
with.

The bottom line is that while there are legitimate arguments to be made in
support of defining a new top-level type rather than just using "application",
this isn't one of them.

> If we agree with that core proposition,

The core proposition isn't now and never has been the issue.

> than incorporating haptic signals
> the aegis of the IETF is the right thing to do,

The goal of the media types registry is to allow for the registration of
anything that functions as a media type, the (very limited) requirements for
which are given in RFC 6838 section 4.1. I interpret that section as not only
saying that media types for novel sorts of data not only are allowed, they can't
be rejected, and I have implemented that interpretation for 20+ years.

I can only recall one recent case where I rejected an application for not
meeting the criteria for a media type, and that was when someone was attempting
to register a media type name for something that in fact was an entire protocol
suite.

Speaking as one of the media type reviewers, it's my assesment that  a
well-defined format for haptic signals currently qualifies for registration
under "application". And had an application been made for the various haptics
subtypes under the "application" tree, they would almost certainly be registered
by now.

> and the time to start that

Well, so far your arguments here strike me as what I grew hearing called "not
even wrong".

> We could also, of course, ignore the work and that proposition.

Again, the only issue we are concerned with here is whether or not a new
top-level type is warranted. Not whether or not haptics stream can be registered
as media types. So let's please stop claiming that this is part of the
problem.

> The likely

I have no crystal ball of any sort, but this is an argument I've heard many
times before: Bad things will happen if we don't bend our process to accommodate 
whatever.

And I have the same problem I always have with such claims: Our process is
perfectly adequate to deal with the matter. Right now nothing seems to be
preventing this work from going forward other than your insistence on it being
done your way. 

> the multimedia landscape than I think you intended.

The mechansism for handing off registration responsibilites to another
organization is actually to define a new registration tree (RFC 6838 section
3.5). The specification is silent as to whether responsibility for a top-level
type can be handed off to a different organization, which I guess means it could
be via a standards action. But this would be a very big step indeed. If haptics
types for some reason required expertise beyond that required for media type
reviews currently, I would think the better way to do it would be for IANA to
find a different set of reviewers with the necessary expertise.

This doesn't mean there aren't issues with defining a new top-level type that
have to be dealt with. There most certainly are. But instead of looking at
those, I'm responding to arguments which, frankly, are rather more FUD-like than
I care for.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 May 2021 15:12:19 -0400

Yeshwant,

Thanks.  I did see your response to Ned, but only after sending
my note.

In what is perhaps an odd way, from my point of view, this is a
good news.  If the document is in FDIS ballot, all of the
suggestions on the this list about how the IETF needs to be
involved, and involved, with some accelerated procedure in order
to influence the substantive decisions of other standards bodies
are moot: as I am sure you know, just about the one way to make
a substantive change in an ISO FDIS document is a "no" vote from
a national member body, presumably after either objecting all
along (which I presume didn't happen) or discovering some
catastrophic substantive problem.  No room for a "we think it
would be better to do this than that" intervention from the IETF.

So the only issues relevant to other SDOs now, AFAICT, is what,
if anything, those documents (which, sadly, I don't have time to
read and study today or even this week) have to say about media
type names.  If the answer is that they don't say anything, then
the IETF should move with appropriate diligence, but should not
put "get it done quickly" ahead of "do it right and get it
right".  If they say "the media type is 'haptics/', then the
IETF is essentially dealing, not with your I-D/ proposal but
with an accomplished fact.  That would present us with a very
different, and unpleasant, situation although, using an
extension of Ted's argument, I think some of us would argue for
registering it and trying to figure out how to avoid that
happening again.  If it references the I-D, I suspect we could
get a note to the editorial team at ISO /CS and/or to the
relevant Committee Manager and secretariat about getting that
fixed even after FDIS balloting was completed (and might get our
way) but whether that would be of substantive importance given
that there is no chance of giving them a stable RFC number as a
reference is, well, questionable.

So now, with the "need to do this quickly to influence the
substantive decisions of other SDOs" and the "the IETF needs to
be influential about this in order to remain an actor in the
multimedia game" aside because, whatever the IETF decides to do
about those issues neither they, nor your I-D, have much, if
anything, to do with them, it seems to me there are only two
questions for  the near term:

* Does the ISO FDIS mention "haptics/" as top-level media type?
If it does, that is a major IETF (and probably IAB) strategy
question, not really a media registration one.  And that
question includes my concern about precedents of other SDOs
squatting on names without including us actively in the
development process.

* If the answer to that is "no", are there objections to more or
less the WG approach Ned suggested that do not rely on the
"influence the work of other SDOs" argument?

thanks,
   john

--On Tuesday, May 4, 2021 17:37 +0000 Yeshwant Muthusamy
<[email-masked]> wrote:

> John,
> 
> 
> 
> Regarding your comment:
> 
> 
> 
>>> One reason is that I think it would be really unfortunate to
>>> establish a precedent that the way to get a top-level media
>>> type is to invoke work going on at
> 
>>> I would feel somewhat differently about an established,
>>> recognized, deployed international standard, but, as I
>>> understand "active work in ..
> 
> I would just reiterate/summarize what I wrote in my response
> to Ned's comment that you might have missed: the haptics
> proposal in MPEG is no longer at the "WG level" in the MPEG
> Systems File Format sub-group. It just progressed to FDIS
> ballot at MPEG134, which should complete by July 2021, at
> which point progression to IS (International Standard) is just
> a matter of procedure. More to the point, it has passed two
> rounds (CDAM and DAMD) of international balloting, with over
> 20 ISO National Bodies casting their ballots in each round. No
> objections to the haptics proposal were received in either
> round.  The proposal left the "WG level" after MPEG131 in July
> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot
> after MPEG132 in October 2020 - a fact that was indeed
> mentioned in v01 of the I-D.
> 
> 
> 
> The ISO link to the DAMD is here:
> https://www.iso.org/standard/81604.html<https://nam10.safelink
> s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan
> dard%2F81604.html&data=04%7C01%7C%7Cb9be185f21b44df1b2f708d90e
> 58c34b%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C0%7C6375565966
> 69589491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qwZKX%2B26U
> WRq%2FPyzp19%2BGfS9J9qG8C6FvmLedDer5w0%3D&reserved=0>.
> 
> 
> 
> To be clear, I have no issues with the other points you raise.
> Just want to make sure that the discussion is based on current
> reality.

---

From: Yeshwant Muthusamy <[email-masked]>
Date: Tue, 4 May 2021 22:44:32 +0000

John,

>>If it does, that is a major IETF (and probably IAB) strategy question, not really a media registration one.

>> And that question includes my concern about precedents of other SDOs squatting on names without including us actively in the development process.

No. The ISOBMFF FDIS does not mention 'haptics/' as top-level media type. That said, it treats haptics in exactly the same way that it treats other top-level media types in Chapter 12 (audio, video, text, font,  etc.) that have been recognized as top-level media types by IETF. To be more specific, our haptics proposal to ISOBMFF follows the same box hierarchy as the other top-level types:

  *   Media handler is 'hapt'
  *   Haptic Media Header is the NullMediaHeaderBox
  *   Sample entry is the HapticSampleEntry

So, there is no issue of ISO squatting on the 'haptics/' name or shutting IETF out from the development process. Our objective was to first introduce haptics as a top-level media type in ISOBMFF and then approach IETF with the proposal that we have in our I-D. For obvious reasons, I am unable to share the DAMD or FDIS documents on this mailing list, but I suspect those who are also members of MPEG can get access to it easily.

>>* If the answer to that is "no", are there objections to more or less the WG approach Ned suggested that do not rely on the "influence the work of other SDOs" argument?

Like I've said before, I am open to whatever mechanism the IETF decides to use to move the I-D forward. Given the work that has already been done in MPEG and the fact that we are approaching the FDIS ballot completion stage, I would assume that the IETF would take that into account *in some form* as it discusses the technical merits of the I-D.

Thanks,

Yeshwant

-----Original Message-----
From: John C Klensin <[email-masked]>
Sent: Tuesday, May 4, 2021 2:12 PM
To: Yeshwant Muthusamy <[email-masked]>; Ted Hardie <[email-masked]>
Cc: Dispatch WG <[email-masked]>; [email-masked]; Applications and Real-Time Area Discussion <[email-masked]>; ART ADs <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [art] [dispatch] Status of Haptics I-D in DISPATCH?

Yeshwant,

Thanks.  I did see your response to Ned, but only after sending my note.

In what is perhaps an odd way, from my point of view, this is a good news.  If the document is in FDIS ballot, all of the suggestions on the this list about how the IETF needs to be involved, and involved, with some accelerated procedure in order to influence the substantive decisions of other standards bodies are moot: as I am sure you know, just about the one way to make a substantive change in an ISO FDIS document is a "no" vote from a national member body, presumably after either objecting all along (which I presume didn't happen) or discovering some catastrophic substantive problem.  No room for a "we think it would be better to do this than that" intervention from the IETF.

So the only issues relevant to other SDOs now, AFAICT, is what, if anything, those documents (which, sadly, I don't have time to read and study today or even this week) have to say about media type names.  If the answer is that they don't say anything, then the IETF should move with appropriate diligence, but should not put "get it done quickly" ahead of "do it right and get it right".  If they say "the media type is 'haptics/', then the IETF is essentially dealing, not with your I-D/ proposal but with an accomplished fact.  That would present us with a very different, and unpleasant, situation although, using an extension of Ted's argument, I think some of us would argue for registering it and trying to figure out how to avoid that happening again.  If it references the I-D, I suspect we could get a note to the editorial team at ISO /CS and/or to the relevant Committee Manager and secretariat about getting that fixed even after FDIS balloting was completed (and might get our

way) but whether that would be of substantive importance given that there is no chance of giving them a stable RFC number as a reference is, well, questionable.

So now, with the "need to do this quickly to influence the substantive decisions of other SDOs" and the "the IETF needs to be influential about this in order to remain an actor in the multimedia game" aside because, whatever the IETF decides to do about those issues neither they, nor your I-D, have much, if anything, to do with them, it seems to me there are only two questions for  the near term:

If it does, that is a major IETF (and probably IAB) strategy question, not really a media registration one.  And that question includes my concern about precedents of other SDOs squatting on names without including us actively in the development process.

* If the answer to that is "no", are there objections to more or less the WG approach Ned suggested that do not rely on the "influence the work of other SDOs" argument?

thanks,

   john

>>> establish a precedent that the way to get a top-level media type is

>>> to invoke work going on at

>>> what I understand to be essentially the WG level in another SDO and

>>> then plead urgency.

>>> I would feel somewhat differently about an established, recognized,

>>> deployed international standard, but, as I understand "active work

>>> in ..

> I would just reiterate/summarize what I wrote in my response to Ned's

> comment that you might have missed: the haptics proposal in MPEG is no

> longer at the "WG level" in the MPEG Systems File Format sub-group. It

> just progressed to FDIS ballot at MPEG134, which should complete by

> July 2021, at which point progression to IS (International Standard)

> is just a matter of procedure. More to the point, it has passed two

> objections to the haptics proposal were received in either round.  The

> proposal left the "WG level" after MPEG131 in July

> 2020 (for the CDAM/CD ballot) and moved to DAMD/DIS ballot after

> MPEG132 in October 2020 - a fact that was indeed mentioned in v01 of

> the I-D.

> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfsKcfbpK8nr

> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfpREaQwDMRV

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

> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C637557523733134949%7CU

> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha

> WwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2BufQx8YrBdXpXyihiMQXkoVkuVKQ6A5E3

> Qz3BQ97HVs%3D&amp;reserved=0<https://nam10.safelinks.protection.outloo

> k.com/?url=https%3A%2F%2Fnam10.safelink%2F&amp;data=04%7C01%7C%7C98c8e

> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1

> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ

> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=yJoFSrPdS6

> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&amp;reserved=0

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 May 2021 21:16:13 -0400

Yeshwant,

Thanks.  And thanks for confirming.  I think I've said as much
as I can usefully say on the subject.

best wishes,
   john

--On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy
<[email-masked]> wrote:

>>> question, not really a media registration one.
> 
>>> And that question includes my concern about precedents of
>>> other SDOs squatting on names without including us actively
>>> in the development process.
> 
> 
> 
> No. The ISOBMFF FDIS does not mention 'haptics/' as top-level
> media type. That said, it treats haptics in exactly the same
> way that it treats other top-level media types in Chapter 12
> (audio, video, text, font,  etc.) that have been recognized as
> top-level media types by IETF. To be more specific, our
> haptics proposal to ISOBMFF follows the same box hierarchy as
> the other top-level types:
> 
> So, there is no issue of ISO squatting on the 'haptics/' name
> or shutting IETF out from the development process. Our
> objective was to first introduce haptics as a top-level media
> type in ISOBMFF and then approach IETF with the proposal that
> we have in our I-D. For obvious reasons, I am unable to share
> the DAMD or FDIS documents on this mailing list, but I suspect
> those who are also members of MPEG can get access to it easily.
> 
> 
> 
>>> * If the answer to that is "no", are there objections to
>>> more or less the WG approach Ned suggested that do not rely
>>> on the "influence the work of other SDOs" argument?
> 
> 
> 
> Like I've said before, I am open to whatever mechanism the
> IETF decides to use to move the I-D forward. Given the work
> that has already been done in MPEG and the fact that we are
> approaching the FDIS ballot completion stage, I would assume
> that the IETF would take that into account *in some form* as
> it discusses the technical merits of the I-D.
> 
> 
> 
> Thanks,
> 
> Yeshwant
> 
> 
> 
> To: Yeshwant Muthusamy <[email-masked]>; Ted Hardie
> <[email-masked]> Cc: Dispatch WG <[email-masked]>;
> [email-masked]; Applications and Real-Time Area
> Discussion <[email-masked]>; ART ADs <[email-masked]>;
> [email-masked]; [email-masked]
> In what is perhaps an odd way, from my point of view, this is
> a good news.  If the document is in FDIS ballot, all of the
> involved, and involved, with some accelerated procedure in
> order to influence the substantive decisions of other
> standards bodies are moot: as I am sure you know, just about
> the one way to make a substantive change in an ISO FDIS
> document is a "no" vote from a national member body,
> presumably after either objecting all along (which I presume
> didn't happen) or discovering some catastrophic substantive
> problem.  No room for a "we think it would be better to do
> this than that" intervention from the IETF.
> 
> 
> 
> So the only issues relevant to other SDOs now, AFAICT, is
> what, if anything, those documents (which, sadly, I don't have
> time to read and study today or even this week) have to say
> about media type names.  If the answer is that they don't say
> anything, then the IETF should move with appropriate
> diligence, but should not put "get it done quickly" ahead of
> "do it right and get it right".  If they say "the media type
> is 'haptics/', then the IETF is essentially dealing, not with
> your I-D/ proposal but with an accomplished fact.  That would
> present us with a very different, and unpleasant, situation
> although, using an extension of Ted's argument, I think some
> of us would argue for registering it and trying to figure out
> how to avoid that happening again.  If it references the I-D,
> I suspect we could get a note to the editorial team at ISO /CS
> and/or to the relevant Committee Manager and secretariat about
> getting that fixed even after FDIS balloting was completed
> (and might get our
> 
> that there is no chance of giving them a stable RFC number as
> a reference is, well, questionable.
> 
> 
> 
> substantive decisions of other SDOs" and the "the IETF needs
> to be influential about this in order to remain an actor in
> the multimedia game" aside because, whatever the IETF decides
> to do about those issues neither they, nor your I-D, have
> much, if anything, to do with them, it seems to me there are
> only two questions for  the near term:
> 
> 
> 
> * If the answer to that is "no", are there objections to more
> or less the WG approach Ned suggested that do not rely on the
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> 
> 
> 
>> John,
> 
>> 
> 
>> 
> 
>> 
> 
>> Regarding your comment:
> 
>> 
> 
>> 
> 
>> 
> 
>>>> type is
>>>> recognized,
>> to Ned's
>> round.  The
>> after

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 May 2021 09:49:41 +0100

Responses in-line.

On Tue, May 4, 2021 at 8:02 PM Ned Freed <[email-masked]> wrote:

> I think it is more this bit that I find telling for the current case:

   The subtype of "application" will often either be the name or include
   part of the name of the application for which the data are intended.
   This does not mean, however, that any application program name may
   simply be used freely as a subtype of "application"; the subtype
   needs to be registered.

Using this approach to naming would mire the inclusion of haptic signals in
pointers to specific applications, where the value is in defining the
methods so that they can be consumed by any compliant application.  If
there were a single haptic signal then application/haptic might well work,
but with a collection of them you are either going to have to define a
bunch of different media types like application/haptic-vibration,
application/haptic-torque, application/haptic-acceleration, or you will
need a grouping mechanism for them.  Since RFC 6838 still allows for the
creation of top-level types, it provides a fairly sensible grouping
mechanism and using it reflects just how different these signals are from
auditory, visual, or textual resources.  The text on this is:

   In some cases, a new media type may not "fit" under any currently
   defined top-level type names.  Such cases are expected to be quite
   rare.  However, if such a case does arise, a new type name can be
   defined to accommodate it.  Definition of a new top-level type name
   MUST be done via a Standards Track RFC; no other mechanism can be
   used to define additional type names.

It is my personal opinion that haptic signals do not "fit" under any
currently definited top-level type name and that putting them under
application as a catch-all will result in either needless pointers to
specific applications or a collection of types which would be better
organized under a new top-level. In other words, I think that haptics fit
the criteria here and that the next step would be to produce the Standards
Track RFC suitable for defining a top level type.

> perfectly adequate to deal with the matter.

This is a misrepresentation of my position.  I am not asking that we not
use our process; I am asking that we *do* use it by assigning or forming a
working group for the work (The ADs having ruled out AD-sponsorship, as is
their prerogative).

Right now nothing seems to be
> preventing this work from going forward other than your insistence on it

This is neither helpful nor accurate. I am not an author of this work; I
responded to an AD request for review and commentary, and I have provided
both, citing each time that it was my personal opinion.  I stand by those
opinions, of course, but this matter is up to the community.

best,

Ted Hardie

---

From: Ned Freed <[email-masked]>
Date: Wed, 05 May 2021 05:42:10 -0700 (PDT)

We now appear to have completely switched from discussing how to structure the
work on a top-level type proposal to arguing about whether or not a new
top-level type has merit. While it's always tempting to correct misconceptions
about how media types work, this is neither the time nor the place to honor this
"call to duty":

    https://xkcd.com/386/

As such, this will be my final message reponding to specific media type issues
until we decide how we're going to do the work.

> methods so that they can be consumed by any compliant application.

In which case, don't use the approach! Do you see any requirements language in
the text you quoted? I don't. What I see is the word "often", and in practice
the majority of media types do *not* use this approach, and more to the point,
do not appear to have been tainted by it.

This even includes proprietary single-vendor types, because these days vendors
often have multiple applications using the same type.

Additionally, the types that seem to be the concern here seem to be ones in the
standards tree, where the only time this sort of name alignment happens is by
happenstance: The name of the type happens to align  with the name of someone's
application.

> If there were a single haptic signal then application/haptic might well work,
> need a grouping mechanism for them.

The names you have chosen here assume that there's a single haptics format for
each type of signal. This is almost certainly a bad idea.

Of course nothing prevents us from encoding the grouping in the subtype name,
and if this information really needs to be extractable, this is the way to do
it.

However, if you want to do this you also need some way to tell applications to
look for the grouping - saying that the presence of a particular word or phrase
in a arbitrary subtype name is also a bad idea.

And this brings us - finally - to a reason to make this a top-level type. The
current draft mentions this in section 2.2, but doesn't actually define such a
convention. Not only does saying such a convention could be defined but not
actually defining essentially nullify the point, the convention needs to be
in place - and used - from the start.

> Since RFC 6838 still allows for the

> specific applications

There is not now, nor has there ever been, a requirement for such
pointers. Some registrations find it helpful to provide a list of
applications that use the type, but many do not, and almost never
in the case of standards tree registrations.

> or a collection of types which would be better

I don't find this argument even close to persuasive, but that's beside the
point: I'm not the person you need to convince and neither are the other people
reading this message.

You also appear to assume I'm against the creation of a top level type. Not that
my personal opinion matters a jot, but I'm actually in favor of it. But having
been through this process several times, I can tell you that not everyone will
be in favor, and you *really* need to have your ducks in a row to succeed, even
more so if you expect to do so in any sort of reasonable time frame.

> working group for the work (The ADs having ruled out AD-sponsorship, as is

No, what you asked for is a separate working to do this work indepenent from
other media types work. And you appear to be alone in wanting this.

> > preventing this work from going forward other than your insistence on it
> > being done your way.

> This is neither helpful nor accurate.

On the contrary, it's both accurate and cuts to the heart of the matter.

You have made a number of assertions here, including but not limited to:

(1) A working chartered to do general media type work would be unable
    to prioritize this work, and will instead be distracted by other
    work items.

(2) There are various semantics attached to the application top-level
    type that either preclude registration of haptics types under it or
    force them to use a nonsensical semantic model.

I have refuted these claims; instead of countering you have in every case
pivoted to different arguments.

				Ned

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 May 2021 16:31:28 +0100

Ned,

In your final response, you cut an important piece of what I had said, so I
restore it here:

>> being

It is severely discourteous to chop off a statement in which I highlighted
that I was giving a personal opinion and would go with the community
decision.

I understand that you don't agree with my opinion (and, unsurprisingly, I
also don't agree with yours), but I am willing to go forward in any way
that the community agrees will make progress, even if it is not the way I
would personally consider optimal.   I am not getting an impression of the
same willingness from you, so it might be best if you stated outright
whether you are willing to go with the community consensus on this.  We can
then leave it up to the ADs to judge that consensus.

Hopefully they have more input than you, me, and John, despite the volume
of the recent exchanges among us; after all, none of us is likely to do the
bulk of the work in the eventual group.

Ted Hardie

---

From: Ned Freed <[email-masked]>
Date: Wed, 05 May 2021 09:01:14 -0700 (PDT)

It would a severe understatment to say I'm flabbergasted by this.

> that I was giving a personal opinion and would go with the community

Unless you have a special status relevant to this effort that I'm unaware of,
everything you say here is a personal opinion. (And so is everything I say,
because I have no special status here either: The fact that some of my comments
are based on my experience as a media type reviewer may give them a bit of
additional weight, but doesn't give them any special status.)

Anyone who fails to evaluate your or my comments just as critically as one
coming from a first time poster isn't doing it right.

As for "going along with the community decision", since I don't know what it
means to not go along with it - more on that below - I assign zero weight to the
statement.

I therefore reject, absolutely and completely, your assertion that it was
severely discourteous to remove this text.

More generally, as far as trimming material goes, my eyesight happens to be
complete crap, and as a result I find it very difficult to pick out the relevant
material from a sea of nested replies. (And for some reason I find trailing text
to be especially distacting - I'm not sure why.)

As a result I tend to be very aggressive in cutting material out of messages -
and that's the reason I removed what I believe to have been irrelevant text.

That said, in some circumstances this may result in context that would have
aided someone else being lost - although I don't see that as being the case
here. But I'm afraid I have little choice but to assign higher priority to my
own ability to participate effectively than to the possibility of
inconveniencing someone else.

> then leave it up to the ADs to judge that consensus.

I'm completely at a loss as to what your concern is here.

What, exactly, would it mean for me - or anyone else - to not be "willing to go
along with the consensus"? Throw a fit? Pray for divine intevention? File an
entirely groundless appeal in hopes of gumming up the works? Go into a funk,
pout, pick up my marbles, and refuse to participate?

And even if I did choose to behave in such a grossly unprofessional manner, so
what? I'm conceited enough to think my personal opinions have sufficient value
to be worth posting, but nowhere near conceited enough to believe that they are
so special and precious that they are even close to being essential to this
effort's success.

And perhaps more to the point, I've been actively involved in the IETF since
1989, and during that time I've been on the losing side of far more
consequential decisions than this more times than I can even count. This
includes quite a few cases where, unlike here, I actually had significant skin
in the game.  Exactly when did my past behavior give you cause to think I would
even consider doing something along these lines?

In any case, since you seem to require assurance on this point, the answer is I
have no problem if the ADs decide to charter two working groups. I would have a
problem with five... but that seems unlikely.

> bulk of the work in the eventual group.

Well, maybe you don't plan on doing significant work in the group or groups, but
I most certainly do: I have every intention of providing feedback on all of the
drafts associated with my media types to-do list, and as I previously stated, I
have every intention of authoring or coauthoring at least one and possibly more
of the drafts themselves.

And to once more assuage your concerns: It won't matter to me in the slightest
if this work happens in one or two groups.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 May 2021 12:34:03 -0700

Hi all,

Thanks for this discussion.  At a minimum, it reaffirms my decision not to
sponsor this myself.  :-)

Francesca and I talked about it this morning after the IESG call, and
decided that I'll take up the pen to write a draft charter based on this
thread and circulate it for comments.  Stay tuned.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 May 2021 11:29:56 -0700 (PDT)

> 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.

> 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.

> 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.).

> 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

> 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
> https://www.mpegstandards.org/standards/Explorations/40/.

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.

				Ned

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 3 May 2021 21:32:45 +0200 (CEST)

>> consider an ID  (or work on it expeditiously),

you totally misread what I stated, sorry. I said that at least those 
companies who are implementing the "new stuff" should be involved into the 
discussion of the specificaions, oitherwise the specification will be just 
ignored or result inaccurate compared to reality. And Apple and Google are 
just 2 examples. The way you read my sentence it totaly against what IETF 
is how it works etc. When I (and Ned and John, and many of the people who 
made suggestions in tis thread) started in the IETF, Apple, Google, and 
80% of current companies weer "just not yet stablished", so please do not 
misread examples. :-) Specifications are done and are successful when all 
people who need them work to write them, and when people who will 
implement them work on them, too.

yes!

---

From: Larry Masinter <[email-masked]>
Date: Wed, 12 May 2021 13:37:02 -0700

Until there is a draft charter and so on, which list should be used to discuss the subject?

What good is any top level type?   What good could it be if we could just change everything? Is there a path from current state to that destination?

For example,  a new top-level type could give some clear advantage in content negotiation. You ask for a thing with some Accept headers, and you expect it to return with something that is acceptable, and the top-level type gives some useful information about the request and/or response).

It could provide a standard for fragment identifiers when applied to all subtypes, for example, time management – you could, given a URL for all timed media could use #start=22.30:end=25.15 as a fragment identifier no matter whether video, audio, haptics, 3d, timed text/captions.

    Or  a “Document” top level type could indicate common fragment components for citations, doi’s, pdfs, ebook to access metadata.

I’m not seeing a use case for haptics/mp9 (or haptics/whatever),  though.

--

 <https://LarryMasinter.net> https://LarryMasinter.net  <https://interlisp.org> https://interlisp.org

From: art <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Thursday, May 6, 2021 12:34 PM
To: John C Klensin <[email-masked]>
Cc: [email-masked]; [email-masked]; Ted Hardie <[email-masked]>; Dispatch WG <[email-masked]>; dispatch chairs <[email-masked]>; Applications and Real-Time Area Discussion <[email-masked]>; Yeshwant Muthusamy <[email-masked]>; ART ADs <[email-masked]>
Subject: Re: [art] [dispatch] Status of Haptics I-D in DISPATCH?

Hi all,

Thanks for this discussion.  At a minimum, it reaffirms my decision not to sponsor this myself.  :-)

Francesca and I talked about it this morning after the IESG call, and decided that I'll take up the pen to write a draft charter based on this thread and circulate it for comments.  Stay tuned.

-MSK

On Tue, May 4, 2021 at 6:16 PM John C Klensin <[email-masked] <mailto:[email-masked]> > wrote:

Yeshwant,

best wishes,
   john

--On Tuesday, May 4, 2021 22:44 +0000 Yeshwant Muthusamy
<[email-masked] <mailto:[email-masked]> > wrote:

> [email-masked] <mailto:[email-masked]>  | +1 469-583-2171
> 
> 
> 
> From: John C Klensin <[email-masked] <mailto:[email-masked]> >
> To: Yeshwant Muthusamy <[email-masked] <mailto:[email-masked]> >; Ted Hardie
> <[email-masked] <mailto:[email-masked]> > Cc: Dispatch WG <[email-masked] <mailto:[email-masked]> >;
> [email-masked] <mailto:[email-masked]> ; Applications and Real-Time Area
> Discussion <[email-masked] <mailto:[email-masked]> >; ART ADs <[email-masked] <mailto:[email-masked]> >;
> [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]> >>
> wrote:
> 
> 
> 
>> John,
> 
>> 
> 
>> 
> 
>> 
> 
>> Regarding your comment:
> 
>> 
> 
>> 
> 
>> 
> 
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A% <https://nam10.safelinks.protection.outlook.com/?url=https%3A%25> 
>> 2F%2Flink
> 
>> protect.cudasvc.com <http://protect.cudasvc.com> %2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o
>> rg%252fst
> 
>> k.com/?url=https%3A%2F%2Fnam10.safelink%2F <http://k.com/?url=https%3A%2F%2Fnam10.safelink%2F&amp;data=04%7C01%257> &amp;data=04%7C01%7
>> C%7C98c8e
> 
>> s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan <http://s.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstan> 
>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 13 May 2021 09:12:37 -0400

> Until there is a draft charter and so on, which list should be used to

feel free to continue to use the dispatch list for this discussion until it
has its own forever home.

> What good is any top level type?   What good could it be if we could just
> change everything? Is there a path from current state to that destination?
>
>
>
> For example,  a new top-level type could give some clear advantage in
> content negotiation. You ask for a thing with some Accept headers, and you
> expect it to return with something that is acceptable, and the top-level
> type gives some useful information about the request and/or response).
>
>
>
> It could provide a standard for fragment identifiers when applied to all
> subtypes, for example, time management – you could, given a URL for all
> timed media could use #start=22.30:end=25.15 as a fragment identifier no
> matter whether video, audio, haptics, 3d, timed text/captions.
>
>     Or  a “Document” top level type could indicate common fragment
> components for citations, doi’s, pdfs, ebook to access metadata.
>
>
>
> https://LarryMasinter.net https://interlisp.org
>
>
>
> *From:* art <[email-masked]> *On Behalf Of *Murray S. Kucherawy
> *Sent:* Thursday, May 6, 2021 12:34 PM
> *To:* John C Klensin <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> Ted Hardie <[email-masked]>; Dispatch WG <[email-masked]>;
> dispatch chairs <[email-masked]>; Applications and Real-Time
> Area Discussion <[email-masked]>; Yeshwant Muthusamy <
> [email-masked]>; ART ADs <[email-masked]>
> *Subject:* Re: [art] [dispatch] Status of Haptics I-D in DISPATCH?
>
>
>
> Hi all,
>
>
>
> >> https://nam10.safelinks.protection.outlook.com/?url=https%3A%
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%25>
> >> 2F%2Flink
> >
> >> k.com/?url=https%3A%2F%2Fnam10.safelink%2F&amp;data=04%7C01%7
> <http://k.com/?url=https%3A%2F%2Fnam10.safelink%2F&amp;data=04%7C01%257>
> >> C%7C98c8e
> >