First, a warning, this is not a short posting.
People may want to consider spawning new threads for discussion of individual
parts of it.
And then, apologia, I have not been consistant about limiting my line-lengths
with hard line feeds.
+ + + + +
now, to get th nit picking out of the way.
Layout: my LW iig clips the footer line(?s) severely on all pp, if future .ps
files could allow .5 inch all round, that would be good.
Spelling: 2 obvious typos exist on the first page, ("use" for user, "ther" for
there).
+ + + + +
On to more substantial issues.
1) the 4th full Para on P1 has:
"...may be preceded by a forward slash or solidus ("/", ASCII 47)."
I recomend
"...may be preceded by a solidus ("/", ASCII 47)."
as being amply clear.
Unicode has "slash" and "solidus", Postscript has "slash", and ASCII (as given
by my programming docs) has "slash", but nowhere have I seen "forward slash"
used in any reference document.
2) "Font-Changing Commmands".
I recomend
"Font-Alteration Commands".
For me, a Font change implys a significant action such as:
Palatino-Roman -> Times-Roman,
since we have provided no mechanism for specification of specific font names,
"Font-Changing" seems wrong, and after consultation of my online thesaurus,
"Alteration" seems the best available term (Qualitification was what I first
thought of, but I dont think even the OED will list that one :-).
3) Smaller & Bigger. I dont like the recomendation of a constant 2 pt
differential. It is awkward for both directions. Neither do I like a formulaic
(ie, 10% change) solution, as it promotes difficulties for non-PS based
displays. The RichText table recomendation is the only plausible approach I can
foresee, and I would suggest that a sample table be cited. Even better would be
provision for specification of the table, with the understanding that some
receivers would have to interpolate or otherwise fudge things.
Also, It is still unclear to me if <Bigger> = </Smaller> (in effect).
I would like to see seperate "Big" and "Small" states recomended, so that
<Bigger> and <Smaller> index into seperate tables. This will allow a slightly
more compact description, especially if a document employs both a Small and a
Big size alternatly:
<Smaller>
...are described in the following sections.
<Bigger><Bold>Formatting Commands</Bold></b>
The text/enriched formatting commands...according to type.
<Bigger><Bold>Font-Changing Commands</Bold></Bigger>
The following formatting commands are intended to alter...
</Smaller>
would suffice, instead of the lengthier:
<Smaller>
...are described in the following sections.
</Smaller><Bigger><Bold>Formatting Commands</Bold></b>
The text/enriched formatting commands...according to type.
<Bigger><Bold>Font-Changing Commands</Bold></Bigger>
<Smaller>The following formatting commands are intended to alter...
</Smaller>
I admit, this is not a common usage, but it is very cheap to support, and
brevity for the transport is desirable. The only down side I can see is that
one might be tempted to code <Bigger> and </Smaller> as synonyms, but that seems
unclean to me.
4) in the section discussing Justification:
"Initially, text/enriched text is filled and fully
justified..."
I think this is stated poorly, it implies that the incoming text has been
transmitted with fill and full justification, which I hope is not the intention
of the standard, as it would require transmition of letter-tracking and kerning
information as well as line width and other matters best defered to the
intelligence of the receivers UA. I think the following is better phrased:
"Initially, text/enriched text is intended to be displayed
fully-justified with appropriate fill, kerning, and
letter-tracking as suits the capabilitys of the receiving
UA. Actual line width is left to the discretion of the
receiver, which is expected to fold lines intelligently
(prefering soft line breaks) to the best of its ability.
The following commands alter that state...."
Since we are allowing non-ASCII charsets, some mention should be made of the
fact that Full-justification is not appropriate to many scripts, and that a
script-appropriate default justification should be resorted to in such cases. (I
am using "script" to refer to the collective written characteristics of a given
language, for those languages for which this is ambiguous, a particular form is
intended, not the multiple forms as a set.)
5) "The center, flushleft, and flushright commands are generally
mutually exclusive,...
Why quibble? either this is preamble, and "generally" should read "intuitivly",
or it is a spec, and "generally" should be stricken.
But, are we intentially flushing any possibility of the following form of 3
column layout:
<L>...</L><C>...</C><R>...</R>
<L>...</L><C>...</C><R>...</R>
and also the following layout (common to TOC/indexes)
<L> Status of this Memo</L><R>i</R>
<L> Abstract</L><R>i</R>
<L> The Text/enriched MIME type</L><R>1</R>
Of course the following might seem like nonesense, but if one postulates support
for bidirectional scripts (ie, arabic), it need not be so interpreted:
<R>i </R><L> Status of this Memo</L>
<R>i </R><L> Abstract</L>
<R>1 </R><L> The Text/enriched MIME type</L>
What would be difficult is multiple <L> (<C>, <R>) implicitly on a common line,
it is only these which need an implicit line break, and nesting disambiguation.
In fact, I am tempted to argue against the use of </L> </C> </R> at all, seems
like things would be more concise without them (if less consistant).
6) "Indent"
I recomend "IndentLeft", consistant terminology is a good defense against
confusion when dealing with bidirectional scripts sa Arabic.
7) "Verbatim"
The present definition ignores the question of how to nest verbatim fragments.
8) "Comment"
I propose an open extension to the comment facility to provide for such things
as explicit fontnames and font size lists, this would allow senders to imply
suppresion of display of text of significant length. Perhaps:
<Comment-AdobeFont> ITC-MoreThan40Char </Comment-AdobeFont>
<Comment-Bigger>14,18,36,72</Comment-Bigger>
<Comment-foo> ... </Comment-foo>
and of course, the degenerate form of
<Comment> ... </Comment>
9) "Non-ASCII character sets"
The first sentance of the second paragraph is obtuse, I had considerable making
sense of it.
The conclusion I have formed is that, charsets comprising multi-byte streams are
subject to misinterpretation when parsed for Text/enriched constructs, and that
we propose to transmit "<<" for apparently literal "<" irregardless of the
actual semantics of the original "<".
The difficulty I see here (poorly expresed by the present text) is that a
non-MIME complient reader will be fed garbage as a result.
This would seem to argue that a content/multiple is doubly mandatory for these.
"It is recognized that the ability to directly display ...
the "<" octet makes this impossible."
I recomend the following:
the "<" octet makes this impossible without preprocessing"
I also think that these facts warrants a reconsideration of the text of subhead
3 under "TheText/enriched MIME type" (page 1), as the two seem contradictory to
me.
10) "Notes for Implementors"
(last Para) "...thus increasing the likelihood that multifont..."
This suggests to me that multiple fonts (Courier, Times-Roman) will be mixed,
not Xxxx-Roman, Xxxx-Oblique ...).
I suggest:
"...thus increasing the likelihood that enriched..."
+ + + + + +
In closing, Kudos are due to the authors for this version, I think It will be
implementable, where its predecessor was not.
--
dana s emery <de19(_at_)umail(_dot_)umd(_dot_)edu>