One document matched: draft-gellens-format-bis-02.txt
Differences from draft-gellens-format-bis-01.txt
Internet Draft: The Text/Plain Format Parameter R. Gellens
Document: draft-gellens-format-bis-02.txt Qualcomm
Expires: April 2004 October 2003
Updates: RFC 2046
Obsoletes: RFC 2646
The Text/Plain Format and DelSp Parameters
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This specification establishes two parameters to be used with the
Text/Plain media type, and, in the presence of these parameters, the
use of trailing whitespace to indicate flowed lines. This results
in an encoding which appears as normal Text/Plain in older
implementations, since it is in fact normal Text/Plain, yet provides
for superior wrapping, flowing, and quoting.
Gellens [Page 1] Expires April 2004
Internet Draft The Format Parameter October 2003
This standard supersedes the one specified in RFC 2646, "The
Text/Plain Format Parameter", and adds the DelSp parameter to
accommodate languages/coded character sets in which ASCII spaces are
not used or appear rarely.
Gellens [Page 2] Expires April 2004
Internet Draft The Format Parameter October 2003
Table of Contents
1. Comments on this Document . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . . 4
4.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 5
4.3. New Media Types . . . . . . . . . . . . . . . . . . . . 5
5. The Format and DelSp Parameters . . . . . . . . . . . . . . 6
5.1. Generating Format=Flowed . . . . . . . . . . . . . . . . 7
5.2. Interpreting Format=Flowed . . . . . . . . . . . . . . 9
5.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
5.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 10
5.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Digital Signatures and Encryption . . . . . . . . . . . 12
5.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 12
5.8. Examples . . . . . . . . . . . . . . . . . . . . . . . 13
6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13
7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Trailing White Space Corruption . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
11. Internationalization Considerations . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
13. Normative References . . . . . . . . . . . . . . . . . . . . 16
14. Informative References . . . . . . . . . . . . . . . . . . 17
15. Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . 17
Intellectual Property Statement . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
1. Comments on this Document
Private comments should be sent to the author. Public comments may
be sent to the IETF 822 mailing list, <ietf-822@imc.org>. To
subscribe, send a message to <ietf-822-request@imc.org> with the
word SUBSCRIBE as the body of the message. Archives for the list
are at <http://www.imc.org/ietf-822/>.
2. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
Gellens [Page 3] Expires April 2004
Internet Draft The Format Parameter October 2003
3. Introduction
Interoperability problems have been observed with erroneous
labelling of paragraph text as Text/Plain, and with various forms of
"embarrassing line wrap." (See section 4.)
Attempts to deploy new media types, such as Text/Enriched [Rich] and
Text/HTML [HTML] have suffered from a lack of backwards
compatibility and an often hostile user reaction at the receiving
end.
What is required is a format which is in all significant ways
Text/Plain, and therefore is quite suitable for display as
Text/Plain, and yet allows the sender to express to the receiver
which lines can be considered a logical paragraph, and thus flowed
(wrapped and joined) as appropriate.
4. The Problem
The Text/Plain media type is the lowest common denominator of
Internet email, with lines of no more than 998 characters (by
convention usually no more than 78), and where the carriage-return
and line-feed (CRLF) sequence represents a line break (see
[MIME-IMT] and [MSG-FMT]).
Text/Plain is usually displayed as preformatted text, often in a
fixed font. That is, the characters start at the left margin of the
display window, and advance to the right until a CRLF sequence is
seen, at which point a new line is started, again at the left
margin. When a line length exceeds the display window, some clients
will wrap the line, while others invoke a horizontal scroll bar.
Text which meets this description is defined by this memo as
"fixed".
Some interoperability problems have been observed with this format:
4.1. Paragraph Text
Many modern programs use a proportional-spaced font, and use CRLF to
represent paragraph breaks. Line breaks are "soft", occurring as
needed on display. That is, characters are grouped into a paragraph
until a CRLF sequence is seen, at which point a new paragraph is
started. Each paragraph is displayed, starting at the left margin
(or paragraph indent), and continuing to the right until a word is
encountered which does not fit in the remaining display width. This
word is displayed at the left margin of the next line. This
continues until the paragraph ends (a CRLF is seen). Extra vertical
Gellens [Page 4] Expires April 2004
Internet Draft The Format Parameter October 2003
space is left between paragraphs.
Text which meets this description is defined by this memo as
"flowed".
Numerous software products erroneously label this format as
Text/Plain, resulting in much user discomfort.
4.2. Embarrassing Line Wrap
As Text/Plain messages are quoted in replies or forwarded messages,
each line gradually increases in length, eventually being
arbitrarily hard wrapped, resulting in "embarrassing line wrap".
This produces text which is at best hard to read, and often confuses
attributions.
Example:
>>>>>>This is a comment from the first message to show a
>quoting example.
>>>>>This is a comment from the second message to show a
>quoting example.
>>>>This is a comment from the third message.
>>>This is a comment from the fourth message.
It can be confusing to assign attribution to lines 2 and 4 above.
In addition, as devices with display widths smaller than 79 or 80
characters become more popular, embarrassing line wrap has become
even more prevalent, even with unquoted text.
Example:
This is paragraph text that is
meant to be flowed across
several lines.
However, the sending mailer is
converting it to fixed text at
a width of 72
characters, which causes it to
look like this when shown on a
PDA with only
30 character lines.
4.3. New Media Types
Gellens [Page 5] Expires April 2004
Internet Draft The Format Parameter October 2003
Attempts to deploy new media types, such as Text/Enriched [Rich] and
Text/HTML [HTML] have suffered from a lack of backwards
compatibility and an often hostile user reaction at the receiving
end.
In particular, Text/Enriched requires that open angle brackets ("<")
and hard line breaks be doubled, with resulting user unhappiness
when viewed as Text/Plain. Text/HTML requires even more alteration
of text, with a corresponding increase in user complaints.
A proposal to define a new media type to explicitly represent the
paragraph form suffered from a lack of interoperability with
currently deployed software. Some programs treat unknown subtypes
of TEXT as an attachment.
What is desired is a format which is in all significant ways
Text/Plain, and therefore is quite suitable for display as
Text/Plain, and yet allows the sender to express to the receiver
which lines can be considered a logical paragraph, and thus flowed
(wrapped and joined) as appropriate.
5. The Format and DelSp Parameters
This specification defines two MIME parameters for use with
Text/Plain:
Name: Format
Value: Fixed, Flowed
Name: DelSp
Value: Yes, No
(Neither the parameter names nor values are case sensitive.)
If Format is not specified, or if the value is not recognized, a
value of Fixed is assumed. The semantics of the Fixed value are the
usual associated with Text/Plain [MIME-IMT].
A Format value of Flowed indicates that the definition of flowed
text (as specified in this memo) was used on generation, and MAY be
used on reception.
If DelSp is not specified, or if its value is not recognized, a
value of No is assumed. The use of DelSp without a Format value of
Flowed is undefined. When creating messages, DelSp SHOULD NOT be
specified in Text content types other than Text/Plain with Format =
Flowed. When receiving messages, DelSp SHOULD be ignored if used in
a Text content type other than Text/Plain with Format = Flowed.
Gellens [Page 6] Expires April 2004
Internet Draft The Format Parameter October 2003
This section discusses flowed text; section 7 provides a formal
definition.
Section 6 discusses interoperability.
Note that this memo describes an on-the-wire format. It does not
address formats for local file storage.
5.1. Generating Format=Flowed
When generating Format=Flowed text, lines SHOULD be 78 characters or
shorter, including any trailing white space and also including any
space added as part of stuffing (see section 5.4). As suggested
values, any paragraph longer than 78 characters in total length
could be wrapped using lines of 72 or fewer characters. While the
specific line length used is a matter of aesthetics and preference,
longer lines are more likely to require rewrapping and to encounter
difficulties with older mailers. It has been suggested that 66
character lines are the most readable.
The restriction to 78 or fewer characters between CRLFs on the wire
is to conform to [MSG-FMT].
(In addition to conformance to [MSG-FMT], there is a historical need
that all lines, even when displayed by a non-flowed-aware program,
will fit in a standard 79- or 80-column screen without having to be
wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit
on a line, the last column is often reserved for a line-wrap
indicator.)
When creating flowed text, the generating agent wraps, that is,
inserts 'soft' line breaks as needed. Soft line breaks are added at
natural wrapping points, such as between words. A soft line break
is a SP CRLF sequence.
There are two techniques for inserting soft line breaks. The older
technique, established by RFC 2646, created a soft line break by
inserting a CRLF after the occurrence of a space. With this
technique, soft line breaks are only possible where white space
already occurs. When this technique is used, the DelSp parameter
SHOULD be used; if used it MUST be set to "no".
The newer technique, suitable for use even with languages/coded
character sets in which the ASCII space character is rare or not
used, creates a soft line break by inserting a SP CRLF sequence.
When this technique is used, the DelSp parameter MUST be used and
MUST be set to "yes". Note that because of space-stuffing (see
section 5.4), when this technique is used and a soft line break is
inserted at a point where a SP already exists (such as between
Gellens [Page 7] Expires April 2004
Internet Draft The Format Parameter October 2003
words), if the SP CRLF sequence is added immediately before the SP,
the pre-existing SP becomes leading and thus requires stuffing. It
is RECOMMENDED that agents avoid this by inserting the SP CRLF
sequence following the existing SP.
Generating agents MAY use either method within each Text/Plain body
part.
Regardless of which technique is used, a generating agent SHOULD NOT
insert white space in an unnatural location, such as into a word (a
sequence of printable characters, not containing spaces, in a
language/coded character set in which spaces are common). If faced
with such a word which exceeds 78 characters (but less than 998
characters, the [SMTP] limit on line length), the agent SHOULD send
the word as is and exceed the 78-character limit on line length.
A generating agent SHOULD:
o Ensure all lines (fixed and flowed) are 78 characters or fewer
in length, counting any trailing space as well as a space added
as stuffing, but not counting the CRLF, unless a word by itself
exceeds 78 characters.
o Trim spaces before user-inserted hard line breaks.
o Space-stuff lines which start with a space, "From ", or ">".
In order to create messages which do not require space-stuffing, and
are thus more aesthetically pleasing when viewed as Format=Fixed, a
generating agent MAY avoid wrapping immediately before ">", "From ",
or space.
(See sections 5.4 and 5.5 for more information on space-stuffing and
quoting, respectively.)
A Format=Flowed message consists of zero or more paragraphs, each
containing one or more flowed lines followed by one fixed line. The
usual case is a series of flowed text lines with blank (empty) fixed
lines between them.
Any number of fixed lines can appear between paragraphs.
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed
unless absolutely necessary (for example, non-US-ASCII (8-bit)
characters over a strictly 7-bit transport such as unextended
[SMTP]). In particular, a message SHOULD NOT be encoded in
Quoted-Printable for the sole purpose of protecting the trailing
space on flowed lines unless the body part is cryptographically
signed or encrypted (see Section 5.6).
Gellens [Page 8] Expires April 2004
Internet Draft The Format Parameter October 2003
The intent of Format=Flowed is to allow user agents to generate
flowed text which is non-obnoxious when viewed as pure, raw
Text/Plain (without any decoding); use of Quoted-Printable hinders
this and may cause Format=Flowed to be rejected by end users.
5.2. Interpreting Format=Flowed
If the first character of a line is a quote mark (">"), the line is
considered to be quoted (see section 5.5). Logically, all quote
marks are counted and deleted, resulting in a line with a non-zero
quote depth, and content. (The agent is of course free to display
the content with quote marks or excerpt bars or anything else.)
Logically, this test for quoted lines is done before any other tests
(that is, before checking for space-stuffed and flowed).
If the first character of a line is a space, the line has been
space-stuffed (see section 5.4). Logically, this leading space is
deleted before examining the line further (that is, before checking
for flowed).
If the line ends in one or more spaces, the line is flowed.
Otherwise it is fixed.
If the line is flowed and DelSp is "yes", the trailing space
immediately prior to the line's CRLF is logically deleted. If the
DelSp parameter is "no" (or not specified, or set to an unrecognized
value), the trailing space is not deleted.
Any remaining trailing spaces are part of the line's content, but
the CRLF of a soft line break is not.
A series of one or more flowed lines followed by one fixed line is
considered a paragraph, and MAY be flowed (wrapped and unwrapped) as
appropriate on display and in the construction of new messages (see
section 5.5).
A line consisting of one or more spaces (after deleting a stuffed
space) is considered a flowed line.
An empty line (just a CRLF) is a fixed line.
Note that, for Unicode text, [Annex-14] provides guidance choosing
at which characters to wrap a line.
5.3. Usenet Signature Convention
Gellens [Page 9] Expires April 2004
Internet Draft The Format Parameter October 2003
There is a convention in Usenet news of using "-- " as the separator
line between the body and the signature of a message. When
generating a Format=Flowed message containing a Usenet-style
separator before the signature, the separator line is sent as-is.
This is a special case; an (optionally quoted) line consisting of
DASH DASH SP is not considered flowed.
5.4. Space-Stuffing
In order to allow for unquoted lines which start with ">", and to
protect against systems which "From-munge" in-transit messages
(modifying any line which starts with "From " to ">From "),
Format=Flowed provides for space-stuffing.
Space-stuffing adds a single space to the start of any line which
needs protection when the message is generated. On reception, if
the first character of a line is a space, it is logically deleted.
This occurs after the test for a quoted line, and before the test
for a flowed line.
On generation, any unquoted lines which start with ">", and any
lines which start with a space or "From " SHOULD be space-stuffed.
Other lines MAY be space-stuffed as desired.
(Note that space-stuffing is similar to dot-stuffing as specified in
[SMTP].)
5.5. Quoting
In Format=Flowed, the canonical quote indicator (or quote mark) is
one or more close angle bracket (">") characters. Lines which start
with the quote indicator are considered quoted. The number of ">"
characters at the start of the line specifies the quote depth.
Flowed lines which are also quoted may require special handling on
display and when copied to new messages.
When creating quoted flowed lines, each such line starts with the
quote indicator.
Note that because of space-stuffing, the lines
>> Exit, Stage Left
and
>>Exit, Stage Left
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".
Gellens [Page 10] Expires April 2004
Internet Draft The Format Parameter October 2003
However, the line
> > Exit, Stage Left
is different. It has a quote-depth of one, and a content of
"> Exit, Stage Left".
When generating quoted flowed lines, an agent needs to pay attention
to changes in quote depth. A sequence of quoted lines of the same
quote depth immediately followed by lines of a different quote depth
SHOULD be encoded as a paragraph, with the last line generated as
fixed and prior lines generated as flowed.
If a receiving agent wishes to reformat flowed quoted lines (joining
and/or wrapping them) on display or when generating new messages,
the lines SHOULD be de-quoted, reformatted, and then re-quoted. To
de-quote, the number of close angle brackets in the quote indicator
at the start of each line is counted. Consecutive lines with the
same quote depth are considered one paragraph and are reformatted
together. To re-quote after reformatting, a quote indicator
containing the same number of close angle brackets originally
present are prefixed to each line.
On reception, if a change in quote depth occurs on a flowed line,
this is an improperly formatted message. The receiver SHOULD handle
this error by using the 'quote-depth-wins' rule, which is to ignore
the flowed indicator and treat the line as fixed. That is, the
change in quote depth ends the paragraph.
In other words, whenever two adjacent lines have different quote
depths, senders should ensure that the earlier line is fixed (does
not end in a space), and receivers should treat the earlier line as
fixed regardless of whether it ends with a space.
For example, consider the following sequence of lines (using '*' to
indicate a soft line break, i.e., SP CRLF, and '#' to indicate a
hard line break, i.e., CRLF):
> Thou villainous ill-breeding spongy dizzy-eyed*
> reeky elf-skinned pigeon-egg!* <--- problem ---<
>> Thou artless swag-bellied milk-livered*
>> dismal-dreaming idle-headed scut!#
>>> Thou errant folly-fallen spleeny reeling-ripe*
>>> unmuzzled ratsbane!#
>>>> Henceforth, the coding style is to be strictly*
>>>> enforced, including the use of only upper case.#
>>>>> I've noticed a lack of adherence to the coding*
>>>>> styles, of late.#
>>>>>> Any complaints?#
Gellens [Page 11] Expires April 2004
Internet Draft The Format Parameter October 2003
The second line ends in a soft line break, even though it is the
last line of the one-deep quote block. The question then arises as
to how this line should be interpreted, considering that the next
line is the first line of the two-deep quote block.
The example text above, when processed according to quote-depth
wins, results in the first two lines being considered as one quoted,
flowed section, with a quote depth of 1; the third and fourth lines
become a quoted, flowed section, with a quote depth of 2.
A generating agent SHOULD NOT create this situation; a receiving
agent SHOULD handle it by giving preference to the quote-depth.
5.6. Digital Signatures and Encryption
If a message is digitally signed or encrypted it is important that
cryptographic processing use the on-the-wire Format=Flowed format.
That is, during generation the message SHOULD be prepared for
transmission, including addition of soft line breaks,
space-stuffing, and [Quoted-Printable] encoding (to protect soft
line breaks) before being digitally signed or encrypted; similarly,
on receipt the message SHOULD have the signature verified or be
decrypted before [Quoted-Printable] decoding and removal of stuffed
spaces, soft line breaks and quote marks, and reflowing.
Note that [OpenPGP] specifies (in section 7.1) that "any trailing
whitespace (spaces, and tabs, 0x09) at the end of any line is
ignored when the cleartext signature is calculated."
Thus it would be possible to add, in transit, a format=flowed header
to a regular, format=fixed vanilla PGP (not PGP/MIME) signed message
and add arbitrary trailing space characters without this addition
being detected. This would change the rendering of the article by a
client which supported format=flowed.
5.7. Line Analysis Table
Lines contained in a Text/Plain body part with Format=Flowed can be
analyzed by examining the start and end of the line. If the line
starts with the quote indicator, it is quoted. If the line ends
with one or more space characters, it is flowed. This is summarized
by the following table:
Starts Ends in
with One or Line
Quote More Spaces Type
------ ----------- ---------------
no no unquoted, fixed
yes no quoted, fixed
Gellens [Page 12] Expires April 2004
Internet Draft The Format Parameter October 2003
no yes unquoted, flowed
yes yes quoted, flowed
5.8. Examples
The following example contains three paragraphs:
`Take some more tea,' the March Hare said to Alice, very
earnestly.
`I've had nothing yet,' Alice replied in an offended tone, `so I
can't take more.'
`You mean you can't take LESS,' said the Hatter: `it's very easy
to take MORE than nothing.'
This could be encoded as follows (using '*' to indicate a soft line
break, that is, SP CRLF sequence, and '#' to indicate a hard line
break, that is, CRLF):
`Take some more tea,' the March Hare said to Alice, very*
earnestly.#
#
`I've had nothing yet,' Alice replied in an offended tone, `so*
I can't take more.'#
#
`You mean you can't take LESS,' said the Hatter: `it's very*
easy to take MORE than nothing.'#
To show an example of quoting, here we have the same exchange,
presented as a series of direct quotes:
>>>Take some more tea.#
>>I've had nothing yet, so I can't take more.#
>You mean you can't take LESS, it's very easy to take*
>MORE than nothing.#
6. Interoperability
Because flowed lines are all-but-indistinguishable from fixed lines,
software which does not recognize Format=Flowed treats flowed lines
as normal Text/Plain (which is what they are). Thus, Format=Flowed
interoperates with older clients, although flowed lines will have
trailing white space inserted.
Gellens [Page 13] Expires April 2004
Internet Draft The Format Parameter October 2003
If a space-stuffed message is received by an agent which handles
Format=Flowed, the space-stuffing is reversed and thus the message
appears unchanged. An agent which is not aware of Format=Flowed
will of course not undo any space-stuffing; thus Format=Flowed
messages may appear with a leading space on some lines (those which
start with a space, ">" which is not a quote indicator, or "From ").
Since lines which require space-stuffing rarely occur, and the
aesthetic consequences of unreversed space-stuffing are minimal,
this is not expected to be a significant problem.
If some lines begin with one or more spaces, the generating agent
MAY space-stuff all lines, to maintain the relative indentation of
the lines when viewed by clients which are not aware of
Format=Flowed.
Messages generated with DelSp=yes and received by clients which are
aware of Format=Flowed but are not aware of the DelSp parameter will
have an extra space remaining after removal of soft line breaks.
Thus, when generating text in languages/coded character sets in
which spaces are common, the generating agent MAY always use the
DelSp=no method.
Hand-aligned text, such as ASCII tables or art, source code, etc.,
SHOULD be sent as fixed, not flowed lines.
7. ABNF
The constructs used in Text/Plain; Format=Flowed body parts are
described using Augmented Backus-Naur Form [ABNF], including the
core rules defined in Appendix A.
fmessage = * ( paragraph / fixed-line )
paragraph = 1*flowed-line fixed-line
fixed-line = fixed / sig-sep
fixed = [non-empty] CRLF
flowed-line = flow-qt / flow-unqt
flow-qt = quote [stuffing] *text-char 1*SP CRLF
flow-unqt = [stuffing] *text-char 1*SP CRLF
non-empty = [quote] [stuffing] *text-char non-sp
non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
; any 7-bit US-ASCII character, excluding
; NUL, CR, LF, and SP
quote = 1*">"
sig-sep = [ quote [stuffing] ] "--" SP CRLF
stuffing = [SP] ; space-stuffed, added on generation if
; needed, deleted on reception
text-char = non-sp / SP
Gellens [Page 14] Expires April 2004
Internet Draft The Format Parameter October 2003
That is, a Format=Flowed message consists of any number of
paragraphs and/or fixed lines; paragraphs need at least one flowed
line.
Without at least one flowed line, there is a series of fixed lines,
each independent. There is no paragraph.
With at least one flowed line, there is a paragraph, and the
received lines can be reformed and flowed to fit the display window
size. This can only be done if the lines are part of a logical
grouping, the paragraph.
8. Failure Modes
8.1. Trailing White Space Corruption
There are systems in existence which alter trailing whitespace on
messages which pass through them. Such systems may strip, or in
rarer cases, add trailing whitespace, in violation of RFC 2821
[SMTP] section 4.5.2.
Stripping trailing whitespace has the effect of converting flowed
lines to fixed lines, which results in a message no worse than if
Format=Flowed had not been used.
Adding trailing whitespace to a Format=Flowed message may result in
a malformed display or reply.
Since most systems which add trailing white space do so to create a
line which fills an internal record format, the result is almost
always a line which contains an even number of characters (counting
the added trailing white space).
One possible avoidance, therefore, would be to define Format=Flowed
lines to use either one or two trailing space characters to indicate
a flowed line, such that the total line length is odd. However,
considering the scarcity of such systems today, it is not worth the
added complexity.
9. Security Considerations
Any security considerations which apply to Text/Plain also apply to
Text/Plain with Format=Flowed.
Gellens [Page 15] Expires April 2004
Internet Draft The Format Parameter October 2003
Section 5.6 discusses the interaction between Format=Flowed and
digital signatures or encryption.
10. IANA Considerations
IANA is requested to add a reference to this specification in the
Text/Plain Media Type registration.
11. Internationalization Considerations
The line wrap and quoting specifications of Format=Flowed may not be
suitable for certain charsets, such as for Arabic and Hebrew
characters that read from right to left. Care should be taken in
applying format=flowed in these cases, as format=fixed combined with
[quoted-printable] encoding may be more suitable.
The DelSp parameter was added specifically to permit Format=Flowed
to be used with languages/coded character sets in which the ASCII
space character is rarely used, or not used at all.
12. Acknowledgments
The DelSp parameter was developed during a series of discussions
among a number of people, including Harald Alvestrand, Grant
Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned
Freed, Alexey Melnikov, John Myers, and Pete Resnick.
Corrections and clarifications to RFC 2646 and early versions of
this draft were pointed out by several people, including Adam
Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn,
Ragho Mahalingam, Greg Troxel, and Dan Wing.
I'm told that NeXT's mail application used a very similar mechanism
(without support for non-Western languages) in 1992.
13. Normative References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
November 1997.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
Gellens [Page 16] Expires April 2004
Internet Draft The Format Parameter October 2003
[MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual,
November 1996.
[Quoted-Printable] Freed, Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
2045, Innosoft, First Virtual, November 1996.
14. Informative References
[Annex-14] Unicode Standard Annex #14, "Line Breaking Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[MSG-FMT] Resnick, "Internet Message Format", RFC 2822, Qualcomm,
April 2001.
[OpenPGP] Callas, Donnerhacke, Finney, Thayer, "OpenPGP Message
Format", RFC 2440, Network Associates, IN-Root-CA Individual Network
e.V., EIS Corporation, November 1998.
[Rich] Resnick, Walker, "The text/enriched MIME Content-type", RFC
1896, QUALCOMM, InterCon, February 1996.
[SMTP] Klensin, "Simple Mail Transfer Protocol", RFC 2821, AT&T
Laboratories, April 2001.
15. Author's Address
Randall Gellens +1 858 651 5115
QUALCOMM Incorporated randy@qualcomm.com
5775 Morehouse Drive
San Diego, CA 92121
USA
Appendix A: Changes from RFC 2646
Substantive:
o Added DelSp parameter to handle languages and coded character
sets in which space is less common or not used.
o Updated text on generating and interpreting to accommodate the
DelSp parameter.
o Changed the limits of 79 or 80 to be 78 in conformance with RFC
2822.
o Added text on generating to clarify that the 78-character limit
includes trailing white space and stuffing.
o Added fmessage to ABNF.
o Changed sig-sep in ABNF to allow stuffing.
Gellens [Page 17] Expires April 2004
Internet Draft The Format Parameter October 2003
o Changed fixed-line to allow empty lines in ABNF.
o Added explanatory text following ABNF.
o Moved text from Abstract to new Introduction; rewrote Abstract.
o Moved interoperability text to new section, and updated.
o Clarified Security Considerations.
o Text on digital signatures now discusses that OpenPGP ignores
trailing white space.
o Mention Unicode Annex 14.
Editorial:
o Added mention of NeXT's mail application to Acknowledgments.
o Updated Acknowledgments.
o Updated [SMTP] reference to 2821.
o Added Notices.
o Split References into Normative and Informative.
o Improved text wording in some areas.
o Standardize on "quote depth", not "quoting depth".
The DelSp parameter was added specifically to permit Format=Flowed
to be used with languages/coded character sets in which the ASCII
space character is rarely used, or not used at all. The DelSp
mechanism was selected despite having been initially rejected as far
too much of a kludge, because among the many different techniques
proposed, it allows for maximum interoperability among clients which
support neither this specification nor RFC 2646, those which do
support RFC 2646 but not this specification, and those that do
support this specification; this set is multiplied by those that
handle languages/coded character sets in which spaces are common,
and in which they are uncommon or not used.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
Gellens [Page 18] Expires April 2004
Internet Draft The Format Parameter October 2003
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 19] Expires April 2004
| PAFTECH AB 2003-2026 | 2026-04-24 07:33:26 |