On Sun, Dec 06, 2009 at 09:22:32PM +0100, Tarek Ziadé wrote:
On Sun, Dec 6, 2009 at 5:37 PM, Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> wrote: [..]
How about turning that file into a real mime message instead of just a set of pseudo mime headers with some pseudo encodings for multiline stuff.
That way the long description could be the body of that message, no more messy recoding needed.
As far as i can tell, all the other optional fields are designed to fit single lines anyway.
The problem is, we may have in the future more multi-line fields so I think we should not use a message-like body.
Could easily hack that in using multipart/alternative messages, given each alternative a meaning. :-)
OTHO we could drop RFC 822 completely and go for a simpler format like json for 1.2..
That would be a less strange option. If the complete compatibility break does no harm then it might be a good option. But I'm not sure which are all the tools that would be consuming this, it might be risky. Note that stuffing it in multipart/alternative messages suffers the same problem, only your encoding/decoding doesn't. PS: As another (possibly bad) alternative you could encode it in base64. Same compatibility problems however, only your proposal doesn't have those AFAIK. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org