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

[Ted Hardie <[e-mail]>]

Responses in-line.

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

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

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
> > into the media types and other aspects of media processing that are under
> > 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
> > 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".
>
> 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
> > 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 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.


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
> being
> done your way.
>

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


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