ietf-822
[Top] [All Lists]

Re: richtext

1992-12-14 18:49:08
Is the richtext content-type going to change? And will the result still
be called richtext?

Nathaniel and I have been throwing around the idea for a separate draft for
MIME richtext during the next phase.  I've added support for ISO-2022-JP
(Japanese) and ISO-2022-KR (Korean) to the current richtext implementation
distributed with metamail, and have prototyped some ISO-10646-UTF support
in an upcoming re-write (not that I have any UTF messages to test it on :-) .

If so, and it is going to change in a non-backwards compatible way,
then I'm going to refrain from implementing it until the dust
settles. If the new version is going to get a different subtype 
(richertext :-), this is no problem, but then minimal MIME compliance
becomes less and less minimal...

There are a few issues about multi-byte character sets that need to be
resolved with respect to MIME richtext.  These can be solved in two ways:
a backwards-compatible way, or a slightly extended way.  The slightly
extended way is actually nicer in some ways.  It all revolves around what
to do with '<' in multi-byte characters.  If they are encoded as '<lt>',
it's backwards-compatible, but then you lose direct readability.

After many hundreds of kilobytes of e-mail with those involved in the metamail
richtext project, I have some proposals which I can post here now, can send to
those who request it individually, or we can leave it for the next round.

Personally I have no major problems with the present version.

Me neither.

There are a few oversights in the minimal compliance requirements

Could you forward them to me, or post them in the mailing list?  Since I'm
the primary richtext implementor for metamail, I'll be very interested in it.

(paragraph support should be mandatory, otherwise </paragraph> is useless)
and the suggested treatment of white space, but these are easily corrected.
Also, the example program does not satisfy the minimal compliance requirements
(it doesn't convert newlines to blank space) and it is too long and
complicated).

The example program wasn't meant to be a richtext formatter - it was meant
to demonstrate the minimum amount of work necessary to convert richtext into
something more or less readable by humans.

Cheers,

Rhys.

<Prev in Thread] Current Thread [Next in Thread>