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

[Ted Hardie <[e-mail]>]

Ned,

In your final response, you cut an important piece of what I had said, so I
restore it here:

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
>

It is severely discourteous to chop off a statement in which I highlighted
that I was giving a personal opinion and would go with the community
decision.

I understand that you don't agree with my opinion (and, unsurprisingly, I
also don't agree with yours), but I am willing to go forward in any way
that the community agrees will make progress, even if it is not the way I
would personally consider optimal.   I am not getting an impression of the
same willingness from you, so it might be best if you stated outright
whether you are willing to go with the community consensus on this.  We can
then leave it up to the ADs to judge that consensus.

Hopefully they have more input than you, me, and John, despite the volume
of the recent exchanges among us; after all, none of us is likely to do the
bulk of the work in the eventual group.

Ted Hardie



>
On Wed, May 5, 2021 at 3:52 PM Ned Freed <[e-mail]> wrote:

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