From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37539 Path: main.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.gnus.general Subject: Re: "> > >" space removal removes too many spaces? Date: Sun, 05 Aug 2001 22:11:12 +0200 Message-ID: <87puaauv1b.fsf@deneb.enyo.de> References: <878zgy62mg.fsf@deneb.enyo.de> <87g0b64l87.fsf@deneb.enyo.de> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035172936 14417 80.91.224.250 (21 Oct 2002 04:02:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:02:16 +0000 (UTC) Return-Path: Return-Path: Original-Received: (qmail 4754 invoked from network); 5 Aug 2001 19:52:54 -0000 Original-Received: from mail.s.netic.de (HELO mail.netic.de) (212.9.160.11) by gnus.org with SMTP; 5 Aug 2001 19:52:54 -0000 Original-Received: by mail.netic.de (Smail3.2.0.111/mail.s.netic.de) via LF.net GmbH Internet Services via remoteip 212.9.163.33 via remotehost mail.enyo.de with esmtp for mail.gnus.org id m15TTxF-001X1oC; Sun, 5 Aug 2001 21:52:53 +0200 (CEST) Original-Received: from [192.168.1.2] (helo=deneb.enyo.de ident=exim) by mail.enyo.de with esmtp (Exim 3.12 #1) id 15TTwg-00083O-00 for ding@gnus.org; Sun, 05 Aug 2001 21:52:18 +0200 Original-Received: from fw by deneb.enyo.de with local (Exim 3.12 #1) id 15TUEy-0000mD-00 for ding@gnus.org; Sun, 05 Aug 2001 22:11:12 +0200 Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Sun, 05 Aug 2001 21:30:32 +0200") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Original-Lines: 33 Xref: main.gmane.org gmane.emacs.gnus.general:37539 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37539 Simon Josefsson writes: >> I've just implemented this logic (at least I think so). > > Looks nice. Fine. Kai, do you think it's okay to commit it? >> Does RFC 2646 really try to solve the problem this way? In this >> case, the RFC is horribly broken. Attaching semantic to QP encoding >> vs. not-encoding is clearly an extremely bad idea, and it certainly >> contradicts the spirit of MIME. > > No, I think that approach is suggested in a couple of places, RFC 2015 > being the only one I can find now (they use it to protect "From"). This is a detail at the transport layer. RFC 2015 (and, in particular, its successor) doesn't fit nicely into the MIME environment anyway. > RFC 2646 suggests an alternate approach, space-stuffing the lines. It > might be cleaner, but it's (slightly) less visually pleasing to > non-RFC 2646 clients. The idea above looks good on all clients that > support QP. But your approach is not compatible with MIME, and RFC 2646 is. I think the following is required by MIME (implicitly or explicitly, I don't know): The transfer encoding shall not alter the semantics of a part, and no information shall be lost during decoding. This goes along with the possiblity of one-pass processing, and it greatly simplifies the implementation of MIME agents. RFCs 2015 and 2646 adhere to this, your proposal does not, I'm afraid.