(Also responding to mail from Stef and Nathaniel.)
I find myself swaying between wanting to pursue some RichText changes
and not. I think that the assorted discussions about changes to be
quite valid, and very much would like RichText to be "prettier" as I
think "option 2" would allow.
However, there are other changes to MIME which might accomplish other,
nice, cosmentic changes, and we have consistently avoided letting such
issues cause delay. For reference:
Minor technical changes are allowed from Proposed to Draft. The term
'minor' does allow incompatibility, but must still be relatively small
stuff with relatively small effort to make the changes.
Nothing we are talking about sounds as if it is required for going
to Proposed. They are tuning-behaviors, rather than basic to the necessary
functionality.
A recent set of activities, in the IESG/IAB, strongly suggests that
purely documentation changes, with no change to technical content, is NOT
viewed as affecting the standards process or timing for a spec. (Large
changes will tend to cause the spec to stay at its current standards level,
for somewhat longer, but the clock is not reset nor does the document,
for example, revert to Proposed.)
Hence, breaking RichText out is NOT required now, so that Nathaniel's
educational objective can easily be retained now, with the option of
breaking it out, later, if we think it should be. The same for
breaking out the two Transfer Encoding algrithms (qtext & hex64).
Hence, I now reverse my previous suggestion that we change the spec, now
to add Option 2.
Dave