Media types (was: Re: UPDATE: IESG Teleconference on May 18, 1995)

John C Klensin <klensin@mail1.reston.mci.net> Wed, 17 May 1995 22:34 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14010; 17 May 95 18:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14006; 17 May 95 18:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23234; 17 May 95 18:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13997; 17 May 95 18:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13991; 17 May 95 18:34 EDT
Received: from mail1.Reston.mci.net by CNRI.Reston.VA.US id aa23229; 17 May 95 18:34 EDT
Received: from jck.reston.mci.net (jck2.Reston.mci.net) by MAIL1.RESTON.MCI.NET (PMDF V5.0-3 #8388) id <01HQMBC7LJXS0000XW@MAIL1.RESTON.MCI.NET>; Wed, 17 May 1995 18:35:21 -0400 (EDT)
Date: Wed, 17 May 1995 18:34:18 -0400
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: Media types (was: Re: UPDATE: IESG Teleconference on May 18, 1995)
X-Sender: klensin@mail1.reston.mci.net (Unverified)
To: Steve Coya <scoya@CNRI.Reston.VA.US>
Cc: Steve Coya <scoya@CNRI.Reston.VA.US>, iesg@CNRI.Reston.VA.US
Message-id: <01HQMBC7Q9GY0000XW@MAIL1.RESTON.MCI.NET>
MIME-version: 1.0
X-Mailer: Windows Eudora Version 2.1b16
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT

>Question on Option 1: If this is approved as an Informational document,
>doesn't asking the IANA to register this basically end up as
>Experimental (or the "standard" way to handle this)?
>
>Would not Experimental be the way to go to avoid the mispreception?

I think we are splitting hairs, but the hairs may be worth splitting.  The
intent of the MIME rules _and_ the IIIR rules is to avoid having something,
once registered, changing out from under us.  That is part of what the IANA
registration (which would happen with a Proposed Standard too) is intended
to accomplish also.  So all three views converge on that point, and there
basically is no "experiment" in the sense that there might be with a protocol.

A restatement of the options would be:

* Informational says that we decided to accept (or advise IANA to accept) a
registration for a top-level type without a standards-track procedure.  The
authors are publishing an RFC to inform us of what they are doing with that
top-level type (RFC publication is not a requirement for subtype
registration under any of the existing or proposed rules).

* Proposed Standard says what it usually says: the community has decided
that this is interesting, important, and useful (the push-back team would
add "enough to be handled as a top-level type") and the constituency who
wants it (at least) think it will work.  If the definition gets into trouble
such that we later have to recycle at proposed and make major changes, some
combination of IESG, the authors/proponents, and IANA will have to sit down
and decide whether "chemical/???" is still appropriate or whether we need to
move to, and register, "chemical-2/???".   We do this all the time with
things like telnet and PPP options, so nothing new is being introduced in
that area.

By this reasoning, Experimental is probably inappropriate.  If I said
otherwise earlier, I just convinced myself differently.
    john