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

[Ned Freed <[e-mail]>]

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.

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

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

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

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

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.

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

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.

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

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