This worries me, too, but I think it is inevitable if we're not going to
hold up the rest of MIME. I'd like to think we can help a little by
keeping the RFC's adjacent -- that is, if the draft standard of MIME is
RFC N, then the new headers document might be N+1 and richtext N+2.
Also, it might be possible to have the base MIME document at least
include a pointer to the richtext document under the rubric of "other
text subtypes". -- NB
Nathaniel,
I think implicit in the docs defining the standards track and the
notion of STD things that aggregate RFCs is the possibility of having a
very short document that is informational, rather than protocol, in
nature and that provides an annotated table of contents to the protocol
pieces. In this case, one might rationally call it "MIME" and try to
establish a practice in which it was the main thing referenced from
other places if they were going to reference only one. One would then
call 1341bis "MIME: Formats and Body Parts" or, preferably, something
more descriptive; 1342bis, "MIME: Message header extensions..." or just
leave it alone.
One of the things that I think would learn by viewing 1341/1342 as an
implementation experiment of the STD notion is that, indeed, people tend
to seize on one and forget the other. "Assigned numbers" is not an
adequate mechanism for establishing a binding--I imagine because it is
issued too infrequently and it is big enough that lots of people pay no
attention to it--but we now have experimental evidence about the
conclusion. So, unless RFC1310 is to be pushed back into "proposed"
:-), we need a better plan of some sort (and I don't think N+1 is going
to be enough, based on recent experience).
I would expect this same problem with the SMTP extensions except that
they are both more independent and more intertwined. One can't really
read, much less implement, the 8bit or Size stuff without the base doc,
and those two are pretty independent of each other. So, while an
"annotated table of contents" RFC might help, it doesn't look as
necessary at the moment as it does for MIME (and, I think, will become
even more so as more content subtypes that as easily could have been in
the main doc except for timing are added).
Greg (and, if you are reading this list, Dave),
Could we ask you to get IESG thinking about this and the associated
general problem?
--john