Re: text/enriched comments

[John Gardiner Myers <jgm+@xxxxxxx>]

Nathaniel Borenstein <nsb@thumper.bellcore.com> writes:
> > The fact that the "verbatim" turns off interpretation of embedded
> > formatting commands significantly increases the complexity of parsers.
> > [...] I can
> > see of no benefit of the turn-off-interpretation directive, what was
> > the reason for it?
>
> To make it easier to generate text/enriched data that includes things,
> e.g. C programs with lots of "<" characters.

If you wan't to include something that isn't text/enriched, don't use
text/enriched.  Use multipart/mixed, with the surrounding text in
text/enriched and included thing in an apropriate content-type.

Compare the respective size and complexity of the minimal
text/richtext and text/enriched parsers.  The text/enriched parser has
at least 50% more code, most of which is for handling verbatim.

Making a composer quote "<" characters and deal with the CRLF
conventions should take 10 lines of code at most.  It's certainly no
more complex than having to deal with quoting "</verbatim>".
The negligible savings you get in the composer are completely
outweighed by the increased complexity of the parser.

If verbatim stays as is, the claim in Appendix B that text/enriched is
a "simplification" of text/richtext should be removed.

> Are you claiming here that "\n" is converted to local conventions by all
> the world's C compilers?

That's what the C language specification requires.

> > putc('\n', stdout);
>
> No, it corresponds to a general desire to have the final line of output
> show up on line-buffered terminals.

Sample code in specifications should follow the specification to the
letter.  Anything else is likely to mislead implementors.  At least in
RFC 1341, that line was commented...

> > ...slightly challenging to include the literal string "</
> > verbatim>" inside of a verbatim environment...
> 
> Well, I'll admit that I haven't read the spec in detail since I wrote
> the last draft nearly half a year ago, but I can't find anything that
> says you can split it there.   This may be an ambiguity in the spec; did
> you simply assume it was OK to break lines at tokens, even without white
> space, or did I actually say that somewhere?

The instant you leave verbatim, there is no longer any directive
against filling.  Since there is no whitespace outside a verbatim,
folding the line there is certainly doing so "intelligently to the
best of its ability."


> > In short, I think verbatim should just turn off filling and
> > justification.  Readers can then treat it as any other command.
> > Composers can easily deal with having to double < and CRLF's.
> 
> Well, I've gone back and forth on this quite a few times.  I guess I
> would certainly concede that if verbatim's going to stay as it is, there
> should also be a "nofill" environment.  My gut feeling is that the
> current version is a lot easier on composing software, though.  Other
> opinions?  -- NB


				_.John