Re: header folding
Glenn Linderman <[email protected]> Thu, 28 Jul 2011 17:57:12 -0700
| Newsgroups | gmane.comp.python.mime.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1784685892==
Content-Type: multipart/alternative;
boundary="------------020009040201070703010705"
This is a multi-part message in MIME format.
--------------020009040201070703010705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 7/26/2011 5:38 AM, R. David Murray wrote:
> 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.
To me, "fold" means to divide _a_ long line into multiple short lines
(less than line length). (Barry calls this split, it seems.)
To me, "wrap" means to divide and join as necessary a set of lines
(sometimes/often a paragraph) to achieve some number of similar length
lines, not to exceed a line length limit, with possibly a shorter one at
the end.
To me, "fill" means to divide and join as necessary a set of lines
(sometimes/often a paragraph) to use as few lines as possible without
exceeding a line length limit, usually resulting in a shorter one at the
end. (Barry seems to have this same definition.)
For all the above, all divisions and joinings happen at white space
sequences, and white space sequences are considered irrelevant in
composition, and are generally reduced to a single space or newline as a
side effect.
I think that if these terms are defined in the RFCs, that those
definitions should be preferred to mine.
Some set of definitions needs to be agreed upon, before sensible
communication can be made about what various algorithms should actually
do, and what policy settings might be named, and what algorithms they
would invoke.
--------------020009040201070703010705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#330033">
On 7/26/2011 5:38 AM, R. David Murray wrote:
<blockquote cite=3D"mid:[email protected]"
type=3D"cite">
<pre wrap=3D"">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.</pre>
</blockquote>
<br>
To me, "fold" means to divide _a_ long line into multiple short
lines (less than line length).=C2=A0 (Barry calls this split, it seem=
s.)<br>
<br>
To me, "wrap" means to divide and join as necessary a set of lines
(sometimes/often a paragraph) to achieve some number of similar
length lines, not to exceed a line length limit, with possibly a
shorter one at the end.<br>
<br>
To me, "fill" means to divide and join as necessary a set of lines
(sometimes/often a paragraph) to use as few lines as possible
without exceeding a line length limit, usually resulting in a
shorter one at the end. (Barry seems to have this same definition.)<b=
r>
<br>
For all the above, all divisions and joinings happen at white space
sequences, and white space sequences are considered irrelevant in
composition, and are generally reduced to a single space or newline
as a side effect.<br>
<br>
I think that if these terms are defined in the RFCs, that those
definitions should be preferred to mine.<br>
<br>
Some set of definitions needs to be agreed upon, before sensible
communication can be made about what various algorithms should
actually do, and what policy settings might be named, and what
algorithms they would invoke.<br>
</body>
</html>
--------------020009040201070703010705--
--===============1784685892==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline