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

[Ned Freed <[e-mail]>]

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

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. Right now nothing seems to be
preventing this work from going forward other than your insistence on it being
done your way. 

> 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