IETF Logo Mail Archive

Re: [ietf-822] Q: Space stuffing (RFC 3676)

Alessandro Vesely <vesely@tana.it> Mon, 18 July 2016 17:59 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBF512D16D for <ietf-822@ietfa.amsl.com>; Mon, 18 Jul 2016 10:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Level:
X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfJILrKVQYs3 for <ietf-822@ietfa.amsl.com>; Mon, 18 Jul 2016 10:59:08 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2589712D0A8 for <ietf-822@ietf.org>; Mon, 18 Jul 2016 10:59:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1468864743; bh=oktC/Tv8UYCwJp4gxMSwLO2R24Nr5kAVc9+xYM66oAM=; l=1068; h=To:References:Cc:From:Date:In-Reply-To; b=L5sqdcp5oAZTyEbNfBFoUvM2tMVTfobQHG1VLACTcC7ZmPD3y8AsM+DKGK8TpPAIp vDsNZoGoAqOnJR5rCakoUElAhTY2GtoSjIuRj5kan1qafrRjwschwanmHZRp0j6pMk Xf/d31thP7kmaX5BkisFnSJ+ojuOeB4qYs2A3Agc=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 18 Jul 2016 19:59:03 +0200 id 00000000005DC053.00000000578D18E7.0000262D
To: Tony Finch <dot@dotat.at>
References: <e15a5fae-6e53-103d-f960-f1f385099e38@tana.it> <alpine.DEB.2.11.1607181438460.25696@grey.csi.cam.ac.uk>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <751f7444-23b4-7813-31ec-7d7cab6c8be3@tana.it>
Date: Mon, 18 Jul 2016 19:59:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1607181438460.25696@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/EV5dKQz_77cVKO4BIeVjSJ0up5M>
Cc: ietf-822@ietf.org
Subject: Re: [ietf-822] Q: Space stuffing (RFC 3676)
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 17:59:10 -0000

On Mon 18/Jul/2016 15:39:43 +0200 Tony Finch wrote:
> Alessandro Vesely <vesely@tana.it> wrote:
>>
>> Section 4.4 of RFC 3676 says:
>>
>>    On generation, any unquoted lines which start with ">", and any lines
>>    which start with a space or "From " MUST be space-stuffed.  Other
>>    lines MAY be space-stuffed as desired.
>>
>> What does "as desired" mean?  If lines are treated at random, it is obviously
>> impossible to tell stuffed spaces from original indentation.
>
> I think it should say that indented lines MUST also be space-stuffed.

Agreed.  I'm puzzled by that paragraph only says /space/ while Section 4.2 (on 
the DelSp parameter) proves full awareness of non-ASCII spaces, such as nbsp 
(160) and the suite of invisible unicode points, not to mention tab (9), that 
an author may use to produce indentation.  Does that deserve errata?

Adding a space in front of each line would make the message appear less garbled 
to users of space-stuffing-unaware clients.  Are such clients so many to 
justify the waste of one more byte per line?

Ale

v2.23.0 | Report a Bug | By Email