text/enriched comments

John Gardiner Myers <jgm+@cmu.edu> Tue, 29 June 1993 01:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05615; 28 Jun 93 21:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05607; 28 Jun 93 21:46 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa22234; 28 Jun 93 21:46 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00741; Mon, 28 Jun 93 21:17:05 EDT
Received: from ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00737; Mon, 28 Jun 93 21:17:04 EDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA24242@X> for ietf-822@dimacs.rutgers.edu; Mon, 28 Jun 93 21:16:59 EDT
Received: via switchmail; Mon, 28 Jun 1993 21:16:58 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.og=tTpC00WBw40bUMo>; Mon, 28 Jun 1993 21:16:37 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.wg=tTne00WBwA0xGRl>; Mon, 28 Jun 1993 21:16:35 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 28 Jun 1993 21:16:33 -0400 (EDT)
Message-Id: <Qg=tTlO00WBwE0xGFx@andrew.cmu.edu>
Date: Mon, 28 Jun 1993 21:16:33 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+@cmu.edu>
To: ietf-822@dimacs.rutgers.edu
Subject: text/enriched comments
Beak: is Not

I finally got around to reading draft-ietf-822ext-text-enriched-02.txt
and have some questions and comments:

The document does not explictly state that formatting commands are
case-insensitive.

The fact that the "verbatim" turns off interpretation of embedded
formatting commands significantly increases the complexity of parsers.
While text/richtext has one special state (comment), text/enriched has
two, with the param state having to watch out for <verbatim>.  I can
see of no benefit of the turn-off-interpretation directive, what was
the reason for it?

The statement about the UNIX newline convention assumption is
nonsensical--it is up to the C language's stdio library to deal with
newline conventions.

The sample parser botches the following stream:

<param><<</param>

What is the purpose of the line of code:

putc('\n', stdout);

at the end of the sample parser?  It does not appear to correspond to
any part of the text/enriched specification.

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