ietf-822
[Top] [All Lists]

Re: text/paragraph summary

1998-03-11 00:10:16
What we're really talking about here is a text format that works well in
text controls, widgets, and gadgets on modern OS's.  In these controls a
line break means "display the next character at the left margin (right for
semetic languages)."  It also means "wrap the text between line break to
fit the display window".  I think we must be explicit about these
characteristics for the definition of text/paragraph.  I don't find the
term "paragraph" very concise.

That's fine. I have no problem with refining the specification of
text/paragraph, provided it doesn't turn into text/enriched. As I said before,
we know this dog doesn't hunt.

The text/paragraph draft says it can be converted to text/plain by
wrapping at 72 columns.  Seems you at least have to same "for example, by
wrapping at 72 columns" as 72 columns or any number of columns is not
specified by text/plain.  Otherwise the draft is also adding definition to
text/plain.

I agree. Actually I think this should be removed. The notion that mechanical
conversion to text/plain is acceptable begs the question of why we're
even bothering with text/paragraph.

So I'm going to stick my neck out here a bit and suggest that the two
characteristics of text/paragraph I'm suggesting above are not clearly in
violation of the text/plain definition. At least I can't see it at the
moment. The meaning of text/plain I get is that "line break means display
next character at the left(right) margin" and "this is the only thing a
line break can be used for."  Further it seems ambiguous about wrapping as
there is no clear discussion of wrappin.  Also it refers "no special
software required" and "as-is" as how you display the text/plain. These
seem very ambiguous and seem to imply things display & editing devices.
Even for the 822 days this seems ambiguous. Is it a VT100 in wrap mode or
not in wrap mode?

Well, it seems clear enough to me:

   Similarly, whether or not line breaks should be added during display
   operations is also a function of the media type. It should not be
   necessary to add any line breaks to display "text/plain" correctly

So if we're really going to do this right, how about another draft that
disambiguates text/plain and says lines must be shorter than 72
characters?  That will provide a double motivation for moving to
text/paragraph faster, no?

Sigh. This is NOT the problem and this is ABSOLUTELY NOT a solution to
anything.

Long lines in text/plain are Good Things. I and many other use them all the
time. But when I use them I intend for them to be just what they are: Long
lines. Not paragraphs that random message processing agents should see fit
to turn into garbage.

Yes, this is display oriented rather than content oriented. Yes, this implies
that the sender has to have some notion of the recipients capabilities and
intentions. Yes, this doesn't blend well with the brave new PDA world. But we
have this tiny little concept in the IETF: We try not bust existing,
standardized usage, which this is, like it or not.

                                Ned

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