Re: MIME type chemical/*

John C Klensin <klensin@mail1.reston.mci.net> Tue, 23 May 1995 19:51 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09611; 23 May 95 15:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09607; 23 May 95 15:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13740; 23 May 95 15:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09600; 23 May 95 15:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09596; 23 May 95 15:51 EDT
Received: from ns.mci.net by CNRI.Reston.VA.US id aa13734; 23 May 95 15:51 EDT
Received: from tp.jck.com (tp.jck.com [198.252.137.7]) by ns.mci.net (8.6.12/8.6.6) with SMTP id PAA13118; Tue, 23 May 1995 15:52:15 -0400
Message-Id: <199505231952.PAA13118@ns.mci.net>
X-Sender: klensin@mail1.reston.mci.net (Unverified)
X-Mailer: Windows Eudora Version 2.1b16
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 23 May 1995 15:50:54 -0400
To: Chris Newman <chrisn+@cmu.edu>
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: MIME type chemical/*
Cc: iesg@CNRI.Reston.VA.US, moore@cs.utk.edu

>Top level MIME types have an additional cost above and beyond subtypes of
>application.  While most MIME clients can be easily configured to support new
>subtypes, many would require a new release to support new top-level types.

Chris,

While I agree with part of your argument, I think this is spurious.  No one
has proposed an applicability statement that says "everyone must support
chemical/".    So, while I agree that handling the top-level type would
almost certainly require a new release, people who need the type will get
that release, and people who don't won't care: "never heard of this
'chemical/' type is sufficient".   And any MIME UA that can't generate a
message of that variety given an unknown top-level type is, IMO, broken.

>In addition, there was a discussion a few months ago on the
>media-types list about what conditions should be met to merit a new
>top-level MIME type.  Rough concensus was never reached, but the
>majority opinion was that additional hardware should be necessary to
>view the type.  The chemical MIME type does not meet this litmus test.

Actually, that was pretty close to my first reaction to this proposal as
well.  But the authors are quite explicitly talking about "viewing" methods
that would require new hardware, e.g., sending a formula or recipe across
the network (in an appropriate subtype) that would be "viewed" by pushing it
directly into a synthesizer that would reproduce the original chemical.   I
wouldn't expect to do that with, e.g., a MIDI player.

>This proposal is a serious departure from the way MIME types are
>named.  MIME top-level types are distinguished not by subject domain,
>but by the type of medium that is needed to transmit or present an
>object of that type.  It does not appear that objects of type
>"chemical" have needs that distinguish them from other types.

Keith, I believe that the "medium...needed to transmit" is more or less
"bits on the wire" for anything that can be transmitted with MIME (there is
an old INTREX cat joke, but...).  The "presentation" issue is, I believe,
pretty close to Chris's "new hardware" notion.  But "video" and "audio" are
no better as descriptions to the type of device (or medium) involved than
"chemical" is, and "text" is much worse.

The question we have to ask ourselves is given that this type meets the
needs of a significant community that would be otherwise unmet, given that
the community in question has reached rough consensus that this is the right
thing to do, given that the potential collection of subtypes and other
structures is likely to far exceed the collection for, e.g., audio, and
given that "viewing" is going to require very special hardware indeed, what
are we to do with the thing?  My first reaction was to register the type and
have them publish as informational, more or less on the "do what you like in
your little corner of the world as long as it is well specified" theory.
But the procedures don't permit that and Harald quite properly stopped me.
The bottom line is that our options may be standards track, revised
procedures, and driving the users away.

They are willing to come to Stockholm and do a presentation on this.  Do you
think it would be worthwhile for us to schedule that?

What is your preference?

   john