text/enriched

I would like to strongly object to the introduction of text/enriched.
Here are my reasons:

1) I have already written a text/richtext parser.  It was easy to
write and I have the funtionality I need.  Adding another new
formatting type to my parser would double or triple the complexity
with no gain.

2) Here at CMU there are a number of richtext generating clients, as
well as a few non-MIME compliant readers.  I've read large
text/richtext documents untranslated without problems.  In particular,
the <nl> didn't bother me as much as the double-spacing effect would
in text/enriched (I can say this for a fact, since ATK textversion 12
uses the same line break algorithm as text/enriched, and I've read
lots of unprocessed ATK files).

3) The <verbatim> command is awful.  It creates an entirely different
document format nested within the enriched format -- something the
MIME multipart was designed to avoid.  If you want "verbatim" text,
use a multipart with a text/plain part.  Since the primary use of
"verbatim" would be including code samples, it would be desirable to
have those samples easily extractable -- which is an automatic bonus
with MIME multipart.

4) Creating yet-another-richtext-format will just force smart clients
to be larger.  If it isn't broken, don't "fix" it.

5) text/enriched does a poorer job of meeting it's first and primary
goal (that of simplicity) than text/richtext does.  This is proven by
the fact that the text/enriched minimal parser is significantly longer

Re: text/enriched

Since I had some strong arguments against the original richtext, I'll
address some of your issues.  Also, those arguments came from experience
writing a parser into a word-processing format (BBN/Slate).

>> I would like to strongly object to the introduction of text/enriched.
>> Here are my reasons:

>> 1) I have already written a text/richtext parser.  It was easy to
>> write and I have the funtionality I need.  Adding another new
>> formatting type to my parser would double or triple the complexity
>> with no gain.

Sorry, you coded to a draft standard.  Things change.

>> 2) Here at CMU there are a number of richtext generating clients, as
>> well as a few non-MIME compliant readers.  I've read large
>> text/richtext documents untranslated without problems.  In particular,
>> the <nl> didn't bother me as much as the double-spacing effect would
>> in text/enriched (I can say this for a fact, since ATK textversion 12
>> uses the same line break algorithm as text/enriched, and I've read
>> lots of unprocessed ATK files).

Maybe so.  

>> 3) The <verbatim> command is awful.  It creates an entirely different
>> document format nested within the enriched format -- something the
>> MIME multipart was designed to avoid.  If you want "verbatim" text,
>> use a multipart with a text/plain part.  Since the primary use of
>> "verbatim" would be including code samples, it would be desirable to
>> have those samples easily extractable -- which is an automatic bonus

Re: text/enriched

>   1) I have already written a text/richtext parser.  It
>   was easy to write and I have the funtionality I need.

That has not been a universal experience, Several of us found 
the original spec to be quite ambiguous as to how certain 
operators should be handled when nested and other things as 
well, many of us were relectant to implement all that 
featurism, I dont have the resources of Microsoft or 
Claris---getting bold/italic/single underline and font 
sizes out of a macintosh is trivial, doing tabs, sub/superscript, 
indented paragraphs, headers and footers is not so easy, 
especially when one wants to support foreign language display.  
Other platforms have different difficultys, but the bottom line 
is that RichText was overly ambitious.

I, and others, argued that it was beyond the resources of this 
committee to attempt a general document markup scheme, and 
since there were commercial alternatives (several with 
poly-platform asperation) we should limit ourselves to 
something more likely to get implemented.

All sorts of functionallity got discussed, even polylingual 
content, and there is no point in rehashing the details here, 
please see the archives from last spring and summer, then this 
winter for details.

Nobody seemed able to come up with a solution to fix RichText.  
When a rewrite was profered, it seemed to fill the bill, and 
it was issued a distinct name to avoid confusion between the 2.  
Neither is an ideal system, given the multiple platforms from 

Email Etiquette

> I am looking for articles or FAQ postings on e-mail etiquette, or
> suggestions for writing (posting) messages.  Any pointers?

My paper

Legal and Ethical Aspects of Computer-Mediated Communication, by
Jacob Palme, The Arachnet Electronic Journal on Virtual Culture, ISSN
1068-5723, June 30, 1993, Volume 1, Issue 4.

may contain some of the things you are looking for.

You can download it by anonymous ftp:
ftp byrd.mu.wvnet.edu
login anonymous
password: users' electronic address
cd /pub/ejvc
get PALME.V1N4

Re: text/enriched

As another implementor of text/richtext, I agree that the original
spec was too ambiguous.  I haven't tried to implement text/enriched
(yet), but on initial reading it seemed to address the problems
I had observed with richtext.

richtext doesn't have to go away, but it can't advance along the
standards track without cleaning up the ambiguities.

Keith

Re: text/enriched

While richtext has it's problems, it's not clear to me why it can't be
fixed (by clarifying the ambiguity, dropping the unnecessary
functionality, etc.) but instead has to be thrown out and redone from
scratch.

While I believe the miniscule complexity of <center> et al is
adequately compensated for by its benefit, the ambiguity of <center>
in richtext could have been dealt with in other ways.  <center> et al
could have been declared illegal in the middle of a line or their
semantics in the middle of a line could have been clarified.
<Center>ing a single word could mean the much same thing as
<indent>ing a single word.

As I've mentioned before on this list, text/enriched is significantly
more complex than text/richtext.  This is primarily caused by the
<verbatim> command, which establishes a completely different lexical
mode.  The effect of <verbatim> is quite noticeable in the minimal
parser and it will similarly affect real parsers.  There is no
practical benefit to compensate for the additional complexity.

--

-- 
_.John G. Myers		Internet: jgm+ <at> CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

Re: text/enriched

To:  ietf-822 <at> dimacs.rutgers.edu
Subject:  Re: text/enriched
Date:  Thu,  5 Aug 1993 14:57:28 -0400 (EDT)

> While richtext has it's problems, it's not clear to me why it can't be
> fixed (by clarifying the ambiguity, dropping the unnecessary
> functionality, etc.) but instead has to be thrown out and redone from
> scratch.

So give it a try!  Write a spec for a revised richtext and see if you can
address the problems with the current one, while still being reasonably
compatible.

Keith

Re: text/enriched

Keith Moore <moore <at> cs.utk.edu> writes:
> So give it a try!  Write a spec for a revised richtext [...]

Sure, I'll put my money where my mouth is.

It would help if Nathaniel would give me the source to RFC 1341, so I
have something to start from.  I won't be able to do anything until
September at least, due to impending vacation and IMAP work.

Re: text/enriched

< While richtext has it's problems, it's not clear to me why it can't be
< fixed (by clarifying the ambiguity, dropping the unnecessary
< functionality, etc.) but instead has to be thrown out and redone from
< scratch.
<
< While I believe the miniscule complexity of <center> et al is adequately
< compensated for by its benefit, the ambiguity of <center> in richtext
< could have been dealt with in other ways.  <center> et al could have been
< declared illegal in the middle of a line or their semantics in the middle
< of a line could have been clarified. <Center>ing a single word could mean
< the much same thing as <indent>ing a single word.
<
< As I've mentioned before on this list, text/enriched is significantly more
< complex than text/richtext.  This is primarily caused by the <verbatim>
< command, which establishes a completely different lexical mode.  The
< effect of <verbatim> is quite noticeable in the minimal parser and it will
< similarly affect real parsers.  There is no practical benefit to
< compensate for the additional complexity.

It took me about 1 day to convert the metamail richtext program to handle
text/enriched as well as text/richtext. (Yes, Nat has the changes.) The code
to handle <verbatim> is tiny (~20 lines of code). Even then, there are
probably other ways of coding it which would be shorter. The so-called
complexity of <verbatim> is a red herring.

					Tony Hansen
			    hansen <at> pegasus.att.com, tony <at> attmail.com
				att!pegasus!hansen, attmail!tony

Re: text/enriched