Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines
On Sat, May 16 2009, Bill Allombert wrote:
> On Sat, May 16, 2009 at 09:31:26PM +1200, Andrew McMillan wrote:
>> On Sat, 2009-05-16 at 02:10 -0500, Manoj Srivastava wrote:
>> >
>> > It is my recollection that each field in the control file (and
>> > perhaps others) was supposed to follow rfc822 (now rfc5322), and that
>> > says:
>> > ,----
>> > | Each header field is logically a single line of characters comprising
>> > | the field name, the colon, and the field body. For convenience
>> > | however, and to deal with the 998/78 character limitations per line,
>> > | the field body portion of a header field can be split into a
>> > | multiple-line representation; this is called "folding". The general
>> > | rule is that wherever this specification allows for folding white
>> > | space (not simply WSP characters), a CRLF may be inserted before any
>> > | WSP.
>> > |
>> > | The process of moving from this folded multiple-line representation
>> > | of a header field to its single line representation is called
>> > | "unfolding". Unfolding is accomplished by simply removing any CRLF
>> > | that is immediately followed by WSP. Each header field should be
>> > | treated in its unfolded form for further syntactic and semantic
>> > | evaluation. An unfolded header field has no length restriction and
>> > | therefore may be indeterminately long.
>> > `----
>> >
>> > So, each field is always one logical line, but may consist of
>> > multiple physical lines.
>> >
>> > I suggest we add explanation like this to the policy document.
>>
>> It seems reasonable that we should follow this manner of
>> specification, but will this introduce any issues for fields which
>> are currently defined as multiple lines?
I think not, since there treating a field header as a single
logical line or as a line with continuation lines is conceptually
indistinguishable (I do not think we need to change any code with the
new explanation).
> I think removing entirely the CRLF is wrong for our purpose: it should be kept
> in the field value and handled as white space by the code that parse
> the field.
> I do that work my own project and it works perfectly fine.
The part that I want to carry on is that conceptually, a field
header is a single line, though it might be distributed over several
physical lines (continuation lines). I don't think the bit about how
unfolding is to be accomplished need go into policy.
manoj
--
The one day you'd sell your soul for something, souls are a glut.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: