| Erik, you have missed the most simple explanation for this, which is what
| I have been saying all along -- nobody cares very much about such a trivial
| little point as whether or not comments nest.
and
| The time for such picking of nits is past. Let's put this sucker to bed.
I haven't been "on the air" since very early in the history of ietf-822.
However, the above comments (and in fact the whole message: <01GGB25
O1KU2934PFW(_at_)HMCVAX(_dot_)CLAREMONT(_dot_)EDU> by Ned is so unbelievable
that I can't
resist the temptation anymore.
You're taking my comments completely out of context.
If "specifics" like the syntax of the markup used on text in MIME is
such a trivial little point that it really doesn't matter what the
result looks like, then I think we need a separate specification for a
proper markup language for mail - independent of RichText. I agree 100%
with Eric's critisism on RichText. If it is too late to change MIME,
then let's put it in another spec.
And now you're asserting that I said things that I never, ever said. Please
reread my comments again, carefully, in context, and then maybe you'll begin to
see what I'm driving at. As it is you're simply making the same sort of
unsubstantiated statements that Erik has been making. In fact, you'd best
reread Erik's very personal attacks on both myself and Nathaniel, which came,
as far as I can tell, completely out of nowhere and were entirely uncalled for.
This provides the necessary context to understand the tone of my reply. I don't
take kindly to being told that I'm a fool, especially when no evidence is
presented to back it up.
Technical details are important. Nobody ever said otherwise. I certainly
_never_ said that they weren't.
But there's a time for making technical changes and a time for closure. The
time for making technical changes is past. It is now time for closure. I need a
specification now. And I am not alone in this. It was the will of working
group, expressed to me in no uncertain terms at the Santa Fe meeting.
There are still things in MIME that I'd like to change, but I think the will of
the Working Group was totally clear on this and I am not about to open any
issues now.
If RichText is not in MIME then RichText will not get implemented in a whole
generation of products. This will reduce the value of RichText tremendously.
(By contrast, while I strongly opposed the removal of the reference to RFC-CHAR
from MIME, I don't think it is something that needs to be in the base document
as much as RichText does. I have given my reasoning on this point so many
times that I'm not going to repeat it here.)
There will be times in the future for technical changes to be made to RichText,
and to the rest of MIME as well. In my responses to this list please note that
I never, ever, commented on the validity or invalidity of the criticisms
levelled at particular aspects of RichText at this late date. In fact, I agreed
with Erik's criticism of comments since I happen to like nested comments (his
justification for the validity of such a feature was completely different from
my own, but that's another story.) By my count Erik has made two technical
points about RichText, and it turned out that he was wrong on one of them.
(Yes, Erik, I know you still don't like comment element syntax, but you have not
voiced the specifics of your new objections yet.)
Bill Janssen has made several similar points (and I value his opinion on this
very highly, because in addition to being far more levelheaded I think his
proposals, which are more semantic in nature, have significant merit) and I
intend to make absolutely sure his points are considered. But Bill is also an
advocate of closure now, revision later.
I will repeat, for the umpteenth time, I want closure NOW. I will sacrifice
minor technical inaccuracies and leave potential problems in the document to
get closure. I am willing to sacrifice RichText if the IESG tells me to, for
that matter. But I am not going to sacrifice it on the basis of a very personal
and objectionable attack from a latecomer to this process.
I volunteer to write it.
Great. Now we'll have two specifications for RichText. This will kill it dead
as a dodo. Of course, that's probably your intention, so I doubt if I'll be
able to dissuade you from doing this if you want to.
I would like to hear about others interested in this and especially
about others who feel "foreign" characters should be done using the
ISO 8879 entity mechanism (instead of "quoted printable" or whatever)
in headers too! Send me mail.
This is a matter for RFC-HEADERS, not MIME. However, if you wanted to try to
lobby for such a thing the time for it is past as well. And you certainly
cannot justify any position that the current header specification was not
debated on the list. I have megabytes of mail to prove otherwise. I will also
point out that RFC-HEADER is not the approach I advocated, but I have gone with
the will of the group on this as well.
Ned