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

[[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. 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.
Conversely, pointing to a public document describing the details of the
encodings will improve your chances of getting the concept accepted by
the IETF.

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

Dale