Background: I have some experience with writing a MIME-compliant mailer,
and have experimented with all the MIME features. I have found no major
problems with any of the body-part or body-type elements, but have found
richtext to be nearly useless as specified, especially concerning the
processing model and the semantics of the language.
[Greg Vaudreuil]
:
| 2) Richtext needs some changes to deal with multi-byte character sets
| and new functionality. It may need to change more often then MIME.
|
| Proposed Solution: Remove Richtext from MIME itself into a separate
| document and standard.
I very strongly support this proposal.
My misgivings about richtext have been documented in a lengthy draft of a
comparison document between richtext and SGML. The persistent lack of
response from the MIME authors on some of the quite substantial criticisms
that I put forth therein clearly indicate (especially with the emotional
response to any criticism on the list with the response "don't delay MIME")
that richtext has not been adequately discussed, nor that has it seen wide
implementation outside of very small groups that have little experience
with document description and processing languages. It should be noted
that richtext has not been well received in circles with such experience.
Some have noted that the specification and the relationship to SGML in
particular smacks of "not invented here", and the arguments against SGML on
the list from the authors have been lightyears off mark and only served to
quell any criticism.
I would, as before, appreciate if MIME contained a mechanism such as
richtext to transfer more than "flat" text, but not richtext as specified.
There have been many important steps taken in this direction in the
International Standards arena, as well as in the de facto standards market.
I am, for natural reasons, inclined towards International Standards and the
Standard Generalized Markup Language (SGML) in particular. I have
previously proposed that we define an SGML application (as per ISO 8879),
using several application conventions to restrict the richness of SGML to
make the resulting application a relatively simple to implement. I have
received nothing but positive (private) responses on this, but only
handwaving from the authors of MIME. I'm in position to provide the
Internet community with a conforming SGML parser that adheres to these
conventions in at least C, C++ and (emacs/common) lisp, which will reduce
the pain of implementation well below the noticeable.
Sorry for the somewhat bitter tone, but I am disgusted with the reception
that criticism to richtext has received and I want to get it out of MIME
and handled seriously in a different context so that it can be a good
thing, instead of an appendage grudgingly accepted because it's there. I
am also quite disappointed (to avoid the vulgar term I would have used)
with the authors of MIME for telling me "oh, great, let's get back to this"
and then avoid the issue.
I would really hate to see a bag on the side of MIME be accepted without
resistance only because nobody cared to remove it in time. I hope there is
such time now, and that removing it may make those who do see a use for the
facility that richtext could have been form a working group whose scope
would better match a richer text format than mail formats (which appears to
discourage text format people from participating).
Best regards,
</Erik>
--
Erik Naggum ISO 8879 SGML +47 295 0313
Oslo, Norway ISO 10744 HyTime
<erik(_at_)naggum(_dot_)no> ISO 9899 C Memento,
terrigena
<SGML(_at_)ifi(_dot_)uio(_dot_)no> ISO 10646 UCS Memento,
vita brevis