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

[Patrick McManus <[e-mail]>]

On Wed, May 12, 2021 at 4:37 PM Larry Masinter <[e-mail]> wrote:

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

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.
>
>
>
> I’m not seeing a use case for haptics/mp9 (or haptics/whatever),  though.
>
>
>
> --
>
> https://LarryMasinter.net https://interlisp.org
>
>
>
> *From:* art <[e-mail]> *On Behalf Of *Murray S. Kucherawy
> *Sent:* Thursday, May 6, 2021 12:34 PM
> *To:* John C Klensin <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> Ted Hardie <[e-mail]>; Dispatch WG <[e-mail]>;
> dispatch chairs <[e-mail]>; Applications and Real-Time
> Area Discussion <[e-mail]>; Yeshwant Muthusamy <
> [e-mail]>; ART ADs <[e-mail]>
> *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 <[e-mail]> wrote:
>
> 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
> <[e-mail]> wrote:
>
> > John,
> >
> >
> >
> > Thanks for the note. Taking each one of your two questions in
> > order:
> >
> >
> >
> >>> * 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.
> >
> >
> >
> > 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
> >
> >
> >
> > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards
> >
> >
> >
> > [e-mail] | [phone]
> >
> >
> >
> > -----Original Message-----
> > From: John C Klensin <[e-mail]>
> > Sent: Tuesday, May 4, 2021 2:12 PM
> > To: Yeshwant Muthusamy <[e-mail]>; Ted Hardie
> > <[e-mail]> Cc: Dispatch WG <[e-mail]>;
> > [e-mail]; Applications and Real-Time Area
> > Discussion <[e-mail]>; ART ADs <[e-mail]>;
> > [e-mail]; [e-mail]
> > 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:
> >
> >
> >
> > * 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
> > <[e-mail]<mailto:[e-mail]>>
> > 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
> >
> >>
> >
> >>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%25>
> >> 2F%2Flink
> >
> >> protect.cudasvc.com%2Furl%3Fa%3Dhttps%253a%252f%252fwww.iso.o
> >> rg%252fst
> >
> >> andard%252f81604.html%26c%3DE%2C1%2CUgSwpQgu6oGkeYZ_zgagOzAfs
> >> KcfbpK8nr
> >
> >> TJxn5cKPD91dPB2D-9v9C2UvBhUd72m1ZTUXkAaAt3-r9nTGAUhqz5d0N-gfp
> >> REaQwDMRV
> >
> >> d7M%2C%26typo%3D1&amp;data=04%7C01%7C%7C98c8e2a934bf4973859d0
> >> 8d90f309c
> >
> >> 50%7C4f05e41a59b8413aae19d5df3dfd0fb5%7C0%7C1%7C6375575237331
> >> 34949%7CU
> >
> >> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> >> TiI6Ik1ha
> >
> >> WwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2BufQx8YrBdXpXyihiMQXkoVk
> >> uVKQ6A5E3
> >
> >> Qz3BQ97HVs%3D&amp;reserved=0<https://nam10.safelinks.protecti
> >> on.outloo
> >
> >> 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
> >
> >> 2a934bf4973859d08d90f309c50%7C4f05e41a59b8413aae19d5df3dfd0fb
> >> 5%7C0%7C1
> >
> >> %7C637557523733134949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> >> wMDAiLCJQ
> >
> >> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=y
> >> JoFSrPdS6
> >
> >> 62usG5UdU7goWWsu%2BXvT7vKr0OxSXoTns%3D&amp;reserved=0
> >
> >> 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.
> >
> >
> >
> >
>
>