Re: header folding

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

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

On Jul 27, 2011, at 04:56 PM, R. David Murray wrote:

>Wrapping is much more like your 'filling', but probably a less precise
>term, as filling does imply maximizing line lengths, while wrapping
>to my ears does not have that connotation as a requirement.

Is it just the guarantee of maximizing line lengths that's missing?

>'refolding', as I've implemented it, consists of taking an existing folded
>header, unfolding it, and then folding it according to the RFC rules and
>recommendations.  This may or may not put the maximum possible number
>of characters on a line, depending on whether the header is structured
>or unstructured and the content of said header.  And it may or may not
>exactly reproduce the original header, depending on how closely the
>original folder and I agree on our interpretation of the RFC rules :)
>(Which is why headers are only refolded by explicit request.)
>
>So, I agree with Stephen, I think 'folding' is the correct term to
>use here.

Okay.  To me 'folding' is closer to 'splitting', while 'wrapping' is closer
'filling' since in what you describe above, there is an 'unfolding' operati=
on
that happens first.  Note too that Emacs's filling doesn't guarantee maximal
line lengths (i.e. fill-column) either since long words can cause previous
lines to be shorter.  That seems analogous to your description above.

-Barry

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

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

iQIcBAEBCAAGBQJOMJrzAAoJEBJutWOnSwa/T6gP/1bHKson15iX8nBPY5eW4CX2
HRLOnyidb45Vc+6gzIdPfvCqAx39Hs0gahN/QxtC43PkhiORy0V/xJrwXrbxta/G
gm+qRfm/IYJXqFrYAWmsvkgtkbwcspmeFkoghcTBp8srs9M5Ex8oGObCprHKc27T
Tr48S/ft8ZANmzsyP++otA0M8h3qgyR+mThnoZScQ1B1Ont195uzk3A1onvLty7t
J6CJHfUY0dB17+nmfk9wr3EoxdewEYCm4/z0wACvi/I4Y7SUOwsYqobkvtBmladX
4UvjXWQe0WK7SekjpYjFzlTkFrgmRooAsPzDwWfP+kJgz2QHbXiR7mNcxMKT+Saq
wBEccZUzcy/I3lks09MXxXKuNZYKhY0CC04zuBhrOgTsmlSCyHBUQhOXaNo+QKfs
p38dgfzRU6KHtTt1pd54Y6nV/j33u3hlwZw0dGm6cVrsse7nCGPnqJ0L01f4mT7Y
YDA4jtc/E1p8NTPwddefIR1/Aay2+N215ItQouPw4vnreVyP78WWy0YhKSL43h/i
J8ueSdeAn6dZDuYMe3qLY8vqtet4lVVjn+JjkEP2+hebqlJfLFW50uPeCof2x4xu
iJKRf4RgH8IZ0XrE3bT95DJCideiEqF6vTuD5+JmaE8BjJlBymXMByQqmercpnIn
ziIwGuGL2MNHbVbaqODm
=bUdE
-----END PGP SIGNATURE-----

--Sig_/cPcGsfwxOGfAp5OBxMc54J6--

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