Um, I was only in a consulting position on RFC 1049, and wasn't listed
on the cover page. Marvin Sirbu was the sole author. As far as I know,
and I could be wrong, mentioning it in the RFC and getting the RFC
approved is the mechanism by which these things happen.
You could query IANA(_at_)isi(_dot_)edu directly.
Actually, I doubt that IANA is the right registry. It's a *number*
registry, and it creates the Internet Numbers document, in which numbers
are assigned for use by various protocols, and there's some sort of
person (sometimes an RFC) behind each assignment. If you want to use a
number, you go off to some person or publication to find out how to do
that.
In this case, you want further extensions to be coordinated with
everybody who speaks RFC-XXXX. I'd suggest that extensions be
documented solely in subsequent RFCs, that then refer back to RFC-XXXX
and describe exactly what extension is being made.
You really have to address the interoperability problem. People are now
using Content-type: values for all kinds of things. There's
``Content-type: text'' coming out of AT&T, and there's some weird
`Content-type: x-uuencode-apple2-random-stuff'' coming out of Erik
Fair's apple.com post office. In Andrew-land, we never thought we'd
ever see other Content-type: values other than what we were used to
putting there, but now there's this problem in that the pre-3/91 version
of AMDS wants to reject any message that has a Content-type:, is going
off-Andrew, and whose content-type isn't X-BE2 in a version that it
recognizes. Thus, info-appletalk(_at_)andrew(_dot_)cmu(_dot_)edu would reject
Erik
Fair's odd postings, rather than just forwarding them without comment.
You must fill in the edges of how mailers should behave when given
documents that they don't understand!
Do MUAs really have to understand *all* those content-types? Do MTAs?
Craig