headers
Simon Josefsson | 3 Nov 19:59
Favicon

Re: Format=Flowed/RFC 2646 Bis (-02)


Randall Gellens <randy <at> qualcomm.com> writes:

> An updated draft which is intended to replace RFC 2646 has been sent
> in; because of the crush of last-minute submissions, there may be a
> delay before the announcement appears.  During this time it is
> available at
> <ftp://ftp.pensive.org/Public/Randy/draft-gellens-format-bis-02.txt>.
>
> This version reflects comments received during IETF Last Call.
>
> The changes from the -01 version are a discussion of OpenPGP's
> stripping of trailing whitespace before calculating the signature,
> mention of Unicode Annex 14, and some text clean-ups/clarifications .

Thanks for adding the OpenPGP discussion.  Given the subtleness of the
issue, I believe the document should not only mention it, but also
give normative advice on how the combination of OpenPGP and
format=flowed is to be implemented.  Otherwise implementors will
ignore the problem, as they do today.

When I look at how to properly implement both OpenPGP and
format=flowed, I can't come to any other conclusion than that security
is more important than maintaining soft paragraph breaks.  That means
a client should not flow OpenPGP signed data, when it present the
outcome as something that OpenPGP guarantee is what the sender sent.
If the client would flow a message, someone in transit may modify the
rendering of a message without being detected by OpenPGP.

Repeating the text from RFC 2440, saying that PGP/MIME aka RFC 3156
(Continue reading)

Permalink | Reply | 14 comments |
headers
Keith Moore | 6 Nov 04:49
Picon

Re: Format=Flowed/RFC 2646 Bis (-02)


I have to say that I find both RFC 2646 and this draft fairly opaque and
somewhat ambiguous.

In particular, what is a "line"?  is it:

- zero or more characters from the canonical form of a body part,
  beginning either at the start of the body part
  or immediately following a CRLF, and ending with a CRLF?

- zero or more characters from the encoded form of a body part,
  beginning either at the start of the body part
  or immediately following a CRLF, and ending with a CRLF
  whether or not it is preceded by a SP?

- zero or more characters from the canonical form of a body part,
  beginning either at the start of the body part
  or immediately following a CRLF, and ending with a CRLF
  that isn't preceded by a SP?

In a charset that isn't compatible with ASCII, are the characters
">", SP, CR, LF treated specially using the values of those characters
from that charset, or are the octet values 0x3E, 0x20, 0x0D, 0x0A, 
treated specially?  does the answer depend on the format in which
the message is stored?  (e.g. if the message is stored in a file
on a system whose native charset is ASCII compatible, line endings
in the storage format might still be a combination of CF and/or LF,
but they will have no significance for the canonical form of the 
text at all, since that will be UTF-16, EBCDIC, whatever.)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Keith Moore | 6 Nov 05:54
Picon

Re: Format=Flowed/RFC 2646 Bis (-02)


ack!  found a few typos in my attempt at rewording :

> c. regardless of the value of the delsp= parameter, if the format=
> parameter has a value of "flowed" the sequence SP CR LF is not treated 
> as a "line break".  (this changes the rule in section 4.1.1 of RFC 2046
> which states that CR and LF are forbidden outside of line breaks)
> 
> 2. The sequence CR LF from the canonical form of the body part, when 
> NOT immediately preceded by SP, is interpreted as a line break. 
  ^^^  add this here

(I hate it when I do that...)

> 5. One or more ">" characters at the start of a line are taken as an indicator
> that the text on that line are a quotation. 
                             ^^ should be "is"

> 7. Since the ">" notation applies to the entire "line" (as defined in #3 above),
> when a quotation line is "wrapped", the entire line SHOULD be presented as if 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  delete this part (it's redundant)
> it were a single quotation (and all at the same level of depth), even if the
> line is "wrapped" for display or presentation purposes.

Keith
Permalink | Reply | 0 comments |
headers
Adam M. Costello | 6 Nov 09:07

Re: Format=Flowed/RFC 2646 Bis (-02)


Keith Moore <moore <at> cs.utk.edu> wrote:

> if the format= parameter has a value of "flowed" the sequence SP CR LF
> is not treated as a "line break".
>
> 3. A "line" consists of zero or more characters which start
> immediately at the beginning of the canonical form of the body part,
> or immediately following a line break.
>
> 4. "Lines" in body parts for which format=flowed MAY be "wrapped" as
> necessary to fit the width of the display or output medium,

Your description misses one subtlety: while one or more flowed lines and
a following fixed line constitute a unit that invites re-wrapping, a
fixed line not preceeded by a flowed line does not invite re-wrapping.
Also, I think "paragraph" is a more intuitive term for the concept
you're calling "line".  It's useful to let "line" continue to mean what
it always has meant: a sequence of characters terminated by CR LF.

You raise a very good point about the charset.  The grammar in section 7
allows only ASCII characters, even though the delsp parameter is being
introduced for the express purpose of better supporting non-ASCII
scripts.  I think that can easily be fixed by redoing the non-sp
production:

non-sp = <any character except NUL, CR, LF, SP>

There are some other issues with the grammar.  First, I don't see the
reason for distinguishing between unquoted lines and quoted lines.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Moore | 6 Nov 14:03
Picon

Re: Format=Flowed/RFC 2646 Bis (-02)


> Your description misses one subtlety: while one or more flowed lines and
> a following fixed line constitute a unit that invites re-wrapping, a
> fixed line not preceeded by a flowed line does not invite re-wrapping.

I would rather treat a "flowed line" as a single entity than as 
multiple entities.  But you're right in that a "fixed line" and "flowed line"
should be presented differently, to the extent possible.  

I also left out space stuffing.

> Also, I think "paragraph" is a more intuitive term for the concept
> you're calling "line". 

I avoided using the term "paragraph" because that has semantics other
than for presentation.

Personally, I don't think the grammar helps much.  Most readers will 
pay less attention to the grammar than the text.  It's more important
to clean up the text than the grammar.  But if the text were cleaned
up, cleaning up the grammar would also be useful.

e.g.

text-body = *( fixed-line / flowed-line ) 
             ( fixed-line / flowed-line / fragment )

fixed-line = [quote] *text-char CRLF

flowed-line = [stuffing] [quote] 1*( *text-char SP CRLF )
(Continue reading)

Permalink | Reply | 1 comment |
headers
ned+ietf-822 | 6 Nov 16:28

Re: Format=Flowed/RFC 2646 Bis (-02)


> I have to say that I find both RFC 2646 and this draft fairly opaque and
> somewhat ambiguous.

> In particular, what is a "line"?  is it:

> - zero or more characters from the canonical form of a body part,
>   beginning either at the start of the body part
>   or immediately following a CRLF, and ending with a CRLF?

> - zero or more characters from the encoded form of a body part,
>   beginning either at the start of the body part
>   or immediately following a CRLF, and ending with a CRLF
>   whether or not it is preceded by a SP?

> - zero or more characters from the canonical form of a body part,
>   beginning either at the start of the body part
>   or immediately following a CRLF, and ending with a CRLF
>   that isn't preceded by a SP?

I'll leave this for Randy to answer.

> In a charset that isn't compatible with ASCII, are the characters
> ">", SP, CR, LF treated specially using the values of those characters
> from that charset, or are the octet values 0x3E, 0x20, 0x0D, 0x0A,
> treated specially?

If a charset isn't compatible with ASCII insofar as CR and LF are concerned it
cannot be used with the text top-level type. (RFC 2046 section 4.1.1.) So this
is a vacuous concern.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam M. Costello | 8 Nov 20:07

Re: Format=Flowed/RFC 2646 Bis (-02)


Keith Moore <moore <at> cs.utk.edu> wrote:

> I avoided using the term "paragraph" because that has semantics other
> than for presentation.

Okay, but I think we need to keep the term "line" referring to its
intuitive and customary sense, so that we can say things like "each
line may begin with one or more quote characters" and "a space at the
beginning or end of a line (after quoting has been removed) acts as a
flag".

I think it would be confusing, therefore, to use a term like "flowed
line" to refer to something that spans multiple lines.  I think the
current meaning of "flowed line" (a line that ends in a space) is more
intuitive.

If "paragraph" needs to be avoided, perhaps a new term could be
invented, like "snake" or "flow-group".

> I don't like using the term "soft" for the SP CR LF sequence in a
> flowed line because it's too easily confused with Q-P soft line
> breaks, even though they have nothing to do with one another.

I was using "soft" to refer just to the SP, not the CR LF.  I was
calling the single spaces at the beginning and end of the line
"stuffing" and "soft", respectively.  Perhaps better names would be
"stuff" and "flow".

> I'm concerned that people will implement format=flowed differently
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 9 Nov 17:47
Favicon
Gravatar

Re: Format=Flowed/RFC 2646 Bis (-02)


At 7:59 PM +0100 11/3/03, Simon Josefsson wrote:

>  Thanks for adding the OpenPGP discussion.  Given the subtleness of the
>  issue, I believe the document should not only mention it, but also
>  give normative advice on how the combination of OpenPGP and
>  format=flowed is to be implemented.  Otherwise implementors will
>  ignore the problem, as they do today.
>
>  When I look at how to properly implement both OpenPGP and
>  format=flowed, I can't come to any other conclusion than that security
>  is more important than maintaining soft paragraph breaks.  That means
>  a client should not flow OpenPGP signed data, when it present the
>  outcome as something that OpenPGP guarantee is what the sender sent.
>  If the client would flow a message, someone in transit may modify the
>  rendering of a message without being detected by OpenPGP.
>
>  Repeating the text from RFC 2440, saying that PGP/MIME aka RFC 3156
>  SHOULD be used in messaging applications, may be sufficient.  Perhaps
>  promote it to MUST within the scope of flowed messages.

The current text says to use quoted-printable to protect the trailing 
spaces so that the signature is calculated on the on-the-wire format:

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,
(Continue reading)

Permalink | Reply | 13 comments |
headers
randy | 9 Nov 20:13
Favicon
Gravatar

(unknown)


pÚP
Message-Id: <p06100404bbd438dd4fff@[12.162.212.214]>
In-Reply-To: <20031108190751.GB10101 <at> nicemice.net>
References: <p06100308bbc1f72bb5de@[192.168.1.13]>
 <20031105224912.1933f3e4.moore <at> cs.utk.edu>
 <20031106080725.GD6420 <at> nicemice.net>
 <20031106080338.0685100e.moore <at> cs.utk.edu>
 <20031108190751.GB10101 <at> nicemice.net>
X-Mailer: Eudora for Mac OS X v6.1a
Date: Sun, 9 Nov 2003 11:12:52 -0800
To: IETF RFC-822 list <ietf-822 <at> imc.org>
From: Randall Gellens <randy <at> qualcomm.com>
Subject: Re: Format=Flowed/RFC 2646 Bis (-02)
Cc: "Adam M. Costello" <ietf-822.amc+0 <at> nicemice.net>,
 Keith Moore <moore <at> cs.utk.edu>, ned+ietf-822 <at> mrochek.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b26

Adam and Keith have obviously spent a lot of time thinking about the 
draft and the underlying issues, and offering specific suggestions 
for improvement.  I am very grateful for this (although it would have 
been even better had this activity occurred sometime earlier in the 
past few years, since most of the text in question hasn't changed in 
some time.)  It's not too late, of course, and it's always preferable 
to improve the clarity of a document prior to publication.

On the questions of the terms "line" and "paragraph", I think it is 
best to keep the concept of "line" as a CRLF-terminated sequence of 
characters (in the canonical encoding).  That way "line" remains a
(Continue reading)

Permalink | Reply | 6 comments |
headers
Simon Josefsson | 14 Nov 01:44
Favicon

Re: Format=Flowed/RFC 2646 Bis (-02)


Randall Gellens <randy <at> qualcomm.com> writes:

> At 7:59 PM +0100 11/3/03, Simon Josefsson wrote:
>
>>  Thanks for adding the OpenPGP discussion.  Given the subtleness of the
>>  issue, I believe the document should not only mention it, but also
>>  give normative advice on how the combination of OpenPGP and
>>  format=flowed is to be implemented.  Otherwise implementors will
>>  ignore the problem, as they do today.
>>
>>  When I look at how to properly implement both OpenPGP and
>>  format=flowed, I can't come to any other conclusion than that security
>>  is more important than maintaining soft paragraph breaks.  That means
>>  a client should not flow OpenPGP signed data, when it present the
>>  outcome as something that OpenPGP guarantee is what the sender sent.
>>  If the client would flow a message, someone in transit may modify the
>>  rendering of a message without being detected by OpenPGP.
>>
>>  Repeating the text from RFC 2440, saying that PGP/MIME aka RFC 3156
>>  SHOULD be used in messaging applications, may be sufficient.  Perhaps
>>  promote it to MUST within the scope of flowed messages.
>
> The current text says to use quoted-printable to protect the trailing
> spaces so that the signature is calculated on the on-the-wire format:
>
> 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.
(Continue reading)

Permalink | Reply | 12 comments |

Gmane