Message232826
| Author | martin.panter |
|---|---|
| Recipients | fredstober, lemburg, martin.panter, r.david.murray, vajrasky |
| Date | 2014-12-17.20:11:15 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1418847075.67.0.651028555221.issue20121@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Okay so maybe the documentation should include these restrictions on encoding: * The data being encoded should only include \r or \n bytes that are part of \n or \r\n newline sequences. Encoding arbitrary non-text data is not supported. * The two kinds of newlines should not be mixed * If \n is used for newlines in the input, the encoder will output \n newlines, and they will need converting to CRLF in a later step to conform to the RFC |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2014-12-17 20:11:15 | martin.panter | set | recipients: + martin.panter, lemburg, r.david.murray, vajrasky, fredstober |
| 2014-12-17 20:11:15 | martin.panter | set | messageid: <1418847075.67.0.651028555221.issue20121@psf.upfronthosting.co.za> |
| 2014-12-17 20:11:15 | martin.panter | link | issue20121 messages |
| 2014-12-17 20:11:15 | martin.panter | create | |