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 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. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org