Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt]

[John C Klensin <[e-mail]>]

--On Friday, October 23, 2020 13:38 +0000 Yeshwant Muthusamy
<[e-mail]> wrote:

> [[YKM]] 'haptics' has been proposed as a first-order media
> type in the ISOBMFF standard (ISO/IEC 14496-12), at the same
> level as 'audio' and 'video', so we could indeed have .mp4
> files that just have haptic tracks in them. The ISBOMFF
> Amendment containing our proposal is expected to issue in
> October 2021 (the January 2022 date in the I-D is an error
> that will be fixed in the next revision). Bullet #1 in Section
> 2.1 talks of 'haptics/mp4' files containing just haptics
> tracks, likely useful for streaming games, haptic files for
> haptic vests, belts, suits, etc.

I think some of the confusion here is that creation of a new
top-level media type is a big deal, both in terms of potential
impact on the Internet and in terms of the number of details
that need to be worked out.  At least one of Dale's comments
(below) is connected to that problem.  So, I would like to
encourage you to think about this a bit differently.

If you are not already in close touch with, and participating
in, ISO/IEC JTC1 SC29 (the body responsible for ISO/IEC
14496-12), make that connection.  If you need help, you might
approach Stephan Wenger, who is IETF's liaison to that SC (see
https://www.ietf.org/about/liaisons/ ).  If they are
establishing the "real" definition for the top-level type and
they (or their MA) are defining or approving the registrations,
ending up with a separate registration system in the IETF -- one
that might not be precisely synchronized -- would be really  bad
news.  

This may suggest a somewhat different approach to what you are
trying to do.  My suggestion (speaking for myself only but with
some small background with IETF Media Type definitions) is that
the ideal way to get the top-level type you are looking for
would start with a request from JTC1 SC29 for this.  The request
should propose a mechanism for ensuring that everything says
synchronized.  One way to do that would be for the authoritative
definitions to be theirs (your I-D goes a small distance in that
direction) and that actual subtyppe registrations use names they
have registered (presumably through their MA) and incorporate
their definitions by reference.

>> Another is that it seems like few of these media formats are
>> non-secret.  There are registrations of media formats that are
>> patent-encumbered, but the specifics of those formats can be
>> documented.  What would really encourage support for a haptics
>> data type is one or more open standards. 

> [[YKM]] As we mention
> in Section 2.5 (Haptic Subtypes (in use)), several haptic
> subtypes like haptics/ahap, haptics/ogg, haptics/ivt are
> already widely in use, in millions of devices around the
> world. It is my understanding that we cannot really register a
> haptics/ahap or haptics/ivt format until the top-level media
> type ('haptics')  is accepted and registered. Given the
> standardization progress in MPEG, it seems most logical to use
> the Standards Track RFC route to get 'haptics' registered as a
> top-level type first.

But this just reinforces the suggestion above.  The IETF cannot
possibly prevent anyone who feels like it from defining a
top-level media type of their own, putting it into use, and
sharing it with their friends or admirers.  In that context, the
purpose of IETF standardization of media types (and IANA
registration of subtypes) is to ensure uniqueness (vastly reduce
the risk of two entities using the same name for different
things) and that there is documentation available and how to
find it.  If "haptics/" with several subtypes is already in
active use, then either there is an existing registration or
assignment system in place on which an IETF definition and
registration procedures should build or an IETF effort should
start with a different name and the understanding that, unless
everyone is on board, the effort could easily build confusion
rather than reducing it.

>> I would probably be informative to prepare draft IANA
>> registrations of the haptics type and two or three subtypes
>> and see how writing up the registrations works out in
>> practice. [[YKM]] I am not sure what you mean by 'draft IANA
>> registrations'. The IANA registration website does not have a
>> provision to specify a new top-level media type. You have to
>> choose from a fixed drop-down list of currently approved
>> top-level types in order to register a new subtype. Given that
>> 'haptics' is not part of the top-level media type list yet, I
>> do not see how I can proceed with a 'draft' registration for
>> any of the subtypes of interest. Am I missing something?

I don't think Dale is but let me say almost the same thing from
a slightly different perspective.  If there is going to be a new
top-level type, your defining document needs to specify exactly
how subtypes will be registered and managed. If there are going
to be submissions to IANA, you should provide a registration
template (or incorporate an existing one by explicit reference)
and I think Dale was asking for examples of that that template
would look like filled in.  You also need to define how
registration applications will be reviewed (see RFC 8126).  And
that brings me back to the suggestion above: especially since
there is probably not broad knowledge of haptics and practices
with them in the IETF, the easiest way to write those sections
(if it is possible) would be to say that me Maintenance Agency
for ISOBMFF (or whatever is actually correct) will register
names and then pass them to IANA for subtype registration,
moving the decision-making out of the IETF's active
responsibilities.

good luck.
   john