Neil -
I'm quite familiar with FrameMaker. I use it on my NeXT.
I think that you raise a valid issue, which can be solved only by a
registration of types. I don't think the mechanism itself is broken, but it
may be made broken if we fail to have a registration mechanism in place.
Here's what I propose:
The new RFC-XXXX itemize all known types as before. I'm not sure if we
should leave the X-mumble loophole for a type or not.
The new RFC-XXXX list a few selected subtypes for the purposes of example
and clarification. These subtypes should be limited to a very small number,
since in effect it makes it mandatory for all implementations to know about
those subtypes.
A separate registry (initially RFC-XYZA) list all the currently assigned
type/subtype pairs. This is intended to be a document that will grow with
time. Furthermore, no implementation is expected to recognize all of them
(just all of the primary types).
RFC-XXXX should expressly forbid the use of any subtype not listed in
RFC-XYZA unless the subtype is prefixed with X-vendor-. X-vendor- subtypes
are expressly documented as non-interoperable, and to be used only for
development purposes prior to the assigning of a registered subtype.
It may be nice to also have a number assigned with all registered
type/subtype combinations. This isn't really necessary, but it may make life
easier for some implementations (particularly in creating an efficient
representation of the message).