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

[Ned Freed <[e-mail]>]

> Yeshwant Muthusamy <[e-mail]> writes:
> > [[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.

This may be the case, but it's not the only, or most important case you need to
make when justifying the creation of a top-level type. In particular, you
need to explain why haptics deserve special recognition rather than living
under application, as a myriad of other things (word processing formats,
spreadsheet formats, automative control formats, etc.) do.

I don't think this is a difficult case to make - it seems to me that haptics
data represents a fundamentally different sort of data in the same way that we
differentiate audio, video, etc. But I think section 2 falls short of making
the case currently.

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

> I'm sure you are right, but that's not addressing the point I made:  If
> the details of an encoding are secret, there is going to be general
> antipathy in the IETF toward recognizing it as an "official" media type.

If by "official" you mean standards tree, you can also replace "antipathy" with
"not going to happen". The specification requirements for standards tree types
(RFC 6838 section 4.10) are quite clear, the consensus behind those
requirements was overwhelming, and I see no reason to believe that has changed.
Indeed, if anything the compromise was to allow specifications for types that
you have to pay to get the specifications.

Of course nothing prevents you from registering a vendor tree type with a name
of the form haptics/vnd.foo. There is no requirement for a publicly available
specification there. And if existing practice must be catered to I suppose you
could make an argument that if a name haptics/foo is already in wide use an
exception could be made to allow that name to be associated with a vendor tree
type. But there is also a good chance that this will be seen as an end run
around the process, and even if succesful, when all is said and done the type
won't be in the standards tree, appearances to the contrary notwithstanding.

> Conversely, pointing to a public document describing the details of the
> encodings will improve your chances of getting the concept accepted by
> the IETF.

While it's possible to register an initial set of media types in a top-level
type proposal, it's definitely not required. And while including illustrative
and noncontroversial examples can be helpful - as noted below - attempting to
resolve every issue you have all at once rarely works well. As such, I
recommend that any potentially problematic registrations be deferred until
after you have the top level type in place.

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

> You understand that you need to write a draft RFC to create the
> top-level type, and to get it accepted.  One thing that helps get any
> draft RFC accepted is to provide examples of the thing you are
> proposing.  In the case of a top-level media type, having the RFC
> include registrations of a number of subtypes is useful, because it
> shows people that there is practical benefit to be gained immediately,
> and also to show them what these subtype registrations look like.
> Ideally, these proposed registrations will point to enough information
> to enable the reader to implement the encoding.

Exactly right.

				Ned