Making world/vrml a standard.

Jan Hardenbergh (
Fri, 10 Feb 95 17:25:00 E

I got curious about what it would take to use world/vrml as a
real MIME content type/subtype. Having participated a little
in the ANSI/PHIGS process and a lot in the X/PEX process,
I wanted to see what was actually involved in making VRML
a standard.

It seems as though getting a content type of "world" will be
a bigger process than actually making VRML a standard. It also
seems to be a separate process. I'd like to see 3D on par with video, etc!

I got a couple of interesting responses to questions. This one
sums up everything I've received. -Jan

From: Keith Moore <>
Subject: Re: Advice on making a new content type?
In-Reply-To: Your message of "Fri, 10 Feb 1995 09:37:16 PST."
Date: Fri, 10 Feb 1995 14:52:39 -0500

Jan Hardenbergh <> writes:

> To: postel <postel@ISI.EDU>
> Subject: Advice on making a new content type?
> Date: Fri, 10 Feb 95 12:23:00 E
> Thanx you very much. The content type "world" (for 3D geometry) is
> not a content type.
> Is it realistic to submit an RFC soon and have a BOF in April in Danvers?
> We are interested in making VRML a standard content subtype of a "world"
> content type. ( There is currently a lot of
> experimentation, but it lacks focus, I think.
> Should there be one RFC to justify 3D as a content type and one for VRML
> as a subtype?

To which Jon Postel <> replies:

> Well you should first develop the specification and have it discussed
> by the folks on the <> mailing list.

My reading of RFC 1521 is that a new top-level type (unlike a new
subtype) MUST be defined by an Internet standards track protocol. So
you would need to submit an Internet-Draft document proposing the new
type, and get the IESG to charter a working group to consider it.

Top-level MIME types exist to allow some default behavior for all
members of the subtype (when details of the subtype aren't known) by
mail user agents and/or gateways.

For instance:

"text/foo; charset=bar" can be treated by a user agent as
"text/plain; charset=bar" if the user agent doesn't
know what to do with text/foo.

"image/*" body parts can be deleted by a gateway that knows its
destination environment cannot support images (as in a voice
mail system)

"audio/*" body parts can be deleted by a mail-to-fax gateway.

For this scheme to work, the number of top-level types must be kept
small, so that gateways and user agents can keep up.

My own opinion is that new top-level types should NOT be approved
unless (a) there is some default behavior that could reasonably be
applied to all of its subtypes, and (b) objects from the new type do
not fit well into any existing top-level type.

This might or might not be the case for the intended use of "world".
(Though even if there is a need for a new top-level type here, "world"
appears to be a poor name for it. I'd much prefer something that
gives a better idea of what kinds of things fit into the type.)


P.S. I'm not opposed to new top-level types in general, since I have
seen categories of objects where a new top-level type seems
appropriate. As an example: consider an "interactive" type where the
normal use of the type requires the recipient to interact with it.
Examples: interactive/telnet-session, interactive/library-catalog,
interactive/irc-channel, interactive/mud.

============================================================ end of stuff.

YON,, Jan C. Hardenbergh, Oki Advanced Products 508-460-8655 =|= 100 Nickerson Rd. Marlborough, MA 01776
Imagination is more important than knowledge - Albert Einstein (1879-1955)