Re: header folding

--===============0069223066==
Content-Type: multipart/signed; micalg=PGP-SHA256;
	boundary="Sig_/lGKDAMPTUz9kInTASAURw1F";
	protocol="application/pgp-signature"

--Sig_/lGKDAMPTUz9kInTASAURw1F
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Jul 26, 2011, at 08:38 AM, R. David Murray wrote:

>On Tue, 26 Jul 2011 13:03:11 +0900, "Stephen J. Turnbull" <stephen@xemacs.=
org> wrote:
>> R. David Murray writes:
>>=20
>>  > the end.  Basically, BaseHeader gets a 'wrap' method, and there is
>>  > a new policy control, 'refold_source' (I'll probably rename it to
>>  > 'rewrap_source', since I expect to apply it also to message
>>  > bodies).
>>=20
>> This bothers me.  Folding and wrapping are two different things.
>>=20
>> Folding is about invertibly reformatting a single logical line to make
>> machines happy during transmission, what wrapping "does" is not 100%
>> clear to me but it's about making people happy.  (I put "does" in
>> quotes because it's not obvious to me that the source of wrapped text
>> necessarily is a single anything, nor that wrapping need be
>> invertible.)
>>=20
>> I grant that people and many MUAs take a different point of view about
>> header folding, but clearly the RFCs have moved away from placing any
>> importance on presentation aspects toward specifying an invertible
>> transformation exactly.  On the other hand, I think that wrapping
>> should place emphasis on presentation.
>
>Hmm.  Makes sense to me.  So you'd rather the method were called "fold"
>and that refold_source remains the name of the policy control.

Stephen makes a good one, one I agree with.

>What's the word for what is done when a text message is made to have
>a line length of less than 78 by using quoted printable (or base64)
>encoding?  Is that also folding?  If there's no existing term in common
>use, folding would make sense to me.  So I have no objection to using
>'fold' consistently in the api and code for these operations.

Haven't we used 'splitting' as a term for this, at least internally, in
previous versions?  That's at least what I think of, and I do think we could
have two knows to control the different functionality:

- To 'split' a line means to take a line longer than a specified maximum, a=
nd
  make it fit into the maximum line length, splitting at whitespace or other
  semantic separators.

- To 'fill' a header means to take the logical contents of the header and
  recombine and resplit it so that each line is as close to the maximum line
  length as possible.  My analogy here is Emacs's M-q (fill-paragraph).

What then is "folding" or "wrapping"?  Maybe no different than the above.

>Can anyone see a use case for controlling folding of headers separately
>from folding of message bodies?  I haven't thought of one, which is why
>I'm thinking one policy knob controls both.

You might have a message body that contains code, in which case you might w=
ant
to fill the headers (using the terminology above), but not fill the body.

Cheers,
-Barry

--Sig_/lGKDAMPTUz9kInTASAURw1F
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOLtgYAAoJEBJutWOnSwa/gJMP/ig10jA2fJstdqaRiDbMYDZw
vcxhXeSJaiwpqfmWUQ4bhrOPiChTsaiq5mRGm34IMH7axDFgjQ4Ny0mskSNUr/NL
ITxn6OtNfJzLX6/8YbKzAlz3mhBj5ODXW2zDQqZP34WUIKfzuSqdth4dCZ60wUGW
E/wSMkssozLIWq9ev6d2vi9u8COqe3IOl5RAkaKnpX6EpqmihMDK/msQcZ3NaC96
a9+JQ+C1bFlqXnohW3jPi01u8z5VTp2D91yXtjuOAT6pYJcEHna1HhSez4846zOj
M3JC8xhztltGn7AfjVInSp8LRPfp6S7g5wVIrDqhAxH5I0bS0Rqgqb+N4RCNz4Ja
JZpTvQ905UncnqLj62KDoRI041F4N09Dt9CwqoSnwEj6AQTjF5bhh5ItF8IpxtyR
OzXGSf0u6d0cgIi86uLgLRc/EaBtyeeeQ09hDL/mgvnD5gkLUS5MI+BuRNNg5Im5
n8Ic5nyKAebkdL0IwclmTNQmf9lfosXMXQIT+XguD6bG9WurFYhu0Y+6+hO02nNz
CoMpEnwBKD87VqORihQcJLux8sziP7MQy6RDoz/rL50iGpmk3d6d2yNvtjnz7oOu
rgAlKDSYREh/ryGipE3S600nS5UYRllfgAWhEhANDsgHzJFlWD4IX2/2MJXtoFoJ
Ia9m2dCTAECeLddUr0Lh
=77c4
-----END PGP SIGNATURE-----

--Sig_/lGKDAMPTUz9kInTASAURw1F--

--===============0069223066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline